JaroslavTulach: /* Can this be done in C++? */ - 2012-09-12 08:36:03

Can this be done in C++?

←Older revision Revision as of 08:36, 12 September 2012
Line 68: Line 68:
In this case '''people''' class is the only one to access the ''prev''/''next'' field. So the encapsulation is kept. On the other hand, this is not generic support. One needs to write the code again and again.
In this case '''people''' class is the only one to access the ''prev''/''next'' field. So the encapsulation is kept. On the other hand, this is not generic support. One needs to write the code again and again.
 +
 +
An attempt to provide general support for such list was provided on the [[Talk:Trait|discussion page]], but while being generic and efficient, it is not really type-safe.

JaroslavTulach: /* Can this be done in C++? */ - 2012-09-05 07:29:39

Can this be done in C++?

←Older revision Revision as of 07:29, 5 September 2012
Line 44: Line 44:
<comments/>
<comments/>
 +
 +
[[NetBeans]] IDE has support for [[C]] and [[C++]] and when you want to support a language in an IDE you probably need knowledge of various corner cases. That is why I asked Vladimir, the project lead. Vladimir suggests to write the ''Person&People'' example like this:
 +
 +
<source lang="cpp">
 +
class person {
 +
private:
 +
person* next;
 +
person* prev;
 +
friend class people;
 +
 +
int age;
 +
char* name;
 +
 +
public;
 +
person(int age, const char* name)
 +
}
 +
 +
class people {
 +
add(const person& p);
 +
remove(const person& p);
 +
}
 +
</source>
 +
 +
In this case '''people''' class is the only one to access the ''prev''/''next'' field. So the encapsulation is kept. On the other hand, this is not generic support. One needs to write the code again and again.

JaroslavTulach: /* Can this be done in Java? */ - 2012-09-04 08:48:48

Can this be done in Java?

←Older revision Revision as of 08:48, 4 September 2012
Line 37: Line 37:
== Can this be done in [[Java]]? ==
== Can this be done in [[Java]]? ==
-
Sort of, just it would be more verbose (as usual in [[Java]]). Instead the ''Listable'' [[trait]] one needs to define a [[Java]] '''interface''' with setters and getters for the ''next'' and ''prev'' properties. Everyone would then have to implement bodies of these methods again and again. With [[Scala]] [[trait]] one's gets that for free (and moreover the access is properly encapsulated). The ''List'' implementation would basically remain the same - the [[Java]] type mechanism is as powerful as [[Scala]]'s in this respect.
+
Sort of, just it would be more verbose (as usual in [[Java]]). Instead the ''Listable'' [[trait]] one needs to define a [[Java]] '''interface''' with setters and getters for the ''next'' and ''prev'' properties. Everyone would then have to implement bodies of these methods again and again. With [[Scala]] [[trait]] one's gets that for free (and moreover the access is properly encapsulated). The ''List'' implementation would basically remain the same - the [[Java]] type mechanism is as powerful as [[Scala]]'s in this respect. The implicit conversion would however not be possible - it would have to be explicit (as usual in [[Java]]).
== Can this be done in [[C++]]? ==
== Can this be done in [[C++]]? ==

JaroslavTulach: /* Can this be done in C++? */ - 2012-09-03 04:57:45

Can this be done in C++?

←Older revision Revision as of 04:57, 3 September 2012
Line 42: Line 42:
One question remains: Can this be emulated in [[C++]]? Mixins are inherently present in [[C++]] as the language supports multiple inheritance. Implicit conversions are indeed there. The only question is whether one can type this correctly without using casts. My early 90ties knowledge of [[C++]] would suggest, one needs casts, but maybe the [[C++]] changed and improved meanwhile. Anyone knows?
One question remains: Can this be emulated in [[C++]]? Mixins are inherently present in [[C++]] as the language supports multiple inheritance. Implicit conversions are indeed there. The only question is whether one can type this correctly without using casts. My early 90ties knowledge of [[C++]] would suggest, one needs casts, but maybe the [[C++]] changed and improved meanwhile. Anyone knows?
 +
 +
<comments/>

JaroslavTulach: /* Implicit Wrapper */ - 2012-09-03 04:56:23

Implicit Wrapper

←Older revision Revision as of 04:56, 3 September 2012
Line 29: Line 29:
<source lang="scala" snippet="effectivelist.point"/>
<source lang="scala" snippet="effectivelist.point"/>
-
In fact, it is more than easy thanks to [[Scala]]'s implicit conversion methods. One can create a subtype that mixes in the ''Point'' as well as ''Listable'' and define an implicit method that converts from ''Point'' to ''ListablePoint''. Then one can add ''Point''s to the list:
+
In fact, it is more than easy thanks to [[Scala]]'s implicit conversion methods. One can create a subtype that mixes in the ''Point'' as well as ''Listable'' and define an implicit method that converts from ''Point'' to ''ListablePoint''. Then one can add instances of ''Point'' class directly to the list:
<source lang="scala" snippet="effectivelist.convert"/>
<source lang="scala" snippet="effectivelist.convert"/>

JaroslavTulach: /* Effective and Encapsulated List */ - 2012-09-03 04:54:27

Effective and Encapsulated List

←Older revision Revision as of 04:54, 3 September 2012
Line 17: Line 17:
<source lang="scala" snippet="effectivelist.list"/>
<source lang="scala" snippet="effectivelist.list"/>
-
The encapsulation is guaranteed (thus the [[OOP]] principles are kept). Of course, given the implementation is a one-to-one copy of the [[C]] list, it is going to be as effective as the [[C]] one. Here is its sample usage:
+
The ''List'' is the only class that operates the ''next'' and ''prev'' fields of its items - the encapsulation is guaranteed (thus the [[OOP]] principles are kept). Of course, given the implementation is a one-to-one copy of the [[C]] list, it is going to be as effective as the [[C]] one. Here is its sample usage:
<source lang="scala" snippet="effectivelist.person"/>
<source lang="scala" snippet="effectivelist.person"/>

JaroslavTulach: /* Effective and Encapsulated List */ - 2012-09-03 04:53:03

Effective and Encapsulated List

←Older revision Revision as of 04:53, 3 September 2012
Line 13: Line 13:
<source lang="scala" snippet="effectivelist.item"/>
<source lang="scala" snippet="effectivelist.item"/>
-
Please note that the definition of ''Listable'' item is using '''private''' access modifiers giving access only to the ''List'' implementation that operates on top of such items. Its [[Java]] type would be '''class''' ''List<T'' '''extends''' ''Listable<T>>'' - e.g. list of elements of type ''T'' that have ''prev'' and ''next'' fields pointing to ''T''. The [[Scala]] version follows:
+
Please note that the definition of ''Listable'' item is using '''private''' access modifiers giving access only to the ''List'' implementation that operates on top of such items. Its [[Java]] type would be '''class''' ''List<T'' '''extends''' ''Listable<T>>'' - e.g. list of elements of type ''T'' that have ''prev'' and ''next'' fields in side them pointing to ''T''. The [[Scala]] version follows:
<source lang="scala" snippet="effectivelist.list"/>
<source lang="scala" snippet="effectivelist.list"/>

JaroslavTulach at 04:52, 3 September 2012 - 2012-09-03 04:52:23

←Older revision Revision as of 04:52, 3 September 2012
Line 13: Line 13:
<source lang="scala" snippet="effectivelist.item"/>
<source lang="scala" snippet="effectivelist.item"/>
-
Then we can create a list that operates on top of such items. Its [[Java]] type would be '''class''' ''List<T'' '''extends''' ''Listable<T>>'' - e.g. list of elements of type ''T'' that have ''prev'' and ''next'' fields pointing to ''T''. The [[Scala]] version follows:
+
Please note that the definition of ''Listable'' item is using '''private''' access modifiers giving access only to the ''List'' implementation that operates on top of such items. Its [[Java]] type would be '''class''' ''List<T'' '''extends''' ''Listable<T>>'' - e.g. list of elements of type ''T'' that have ''prev'' and ''next'' fields pointing to ''T''. The [[Scala]] version follows:
<source lang="scala" snippet="effectivelist.list"/>
<source lang="scala" snippet="effectivelist.list"/>
-
Please note that the definition of ''Listable'' item is using '''private''' access modifiers giving access only to the ''List'' implementation. The encapsulation is guaranteed (thus the [[OOP]] principles are kept). Of course, given the implementation is a one-to-one copy of the [[C]] list, it is going to be as effective as the [[C]] one. Here is its sample usage:
+
The encapsulation is guaranteed (thus the [[OOP]] principles are kept). Of course, given the implementation is a one-to-one copy of the [[C]] list, it is going to be as effective as the [[C]] one. Here is its sample usage:
<source lang="scala" snippet="effectivelist.person"/>
<source lang="scala" snippet="effectivelist.person"/>

JaroslavTulach: /* Can this be done in Java? */ - 2012-09-02 23:51:45

Can this be done in Java?

←Older revision Revision as of 23:51, 2 September 2012
Line 37: Line 37:
== Can this be done in [[Java]]? ==
== Can this be done in [[Java]]? ==
-
Sort of, just it would be more verbose (as usual in [[Java]]). Instead the ''Listable'' [[trait]] one needs to define a [[Java]] '''interface''' with setters and getters for the ''next'' and ''prev'' properties. Everyone would then have to implement bodies of these methods again and again. With [[Scala]] [[trait]] one's gets that for free. The ''List'' implementation would basically remain the same - the [[Java]] type mechanism is as powerful as [[Scala]]'s in this respect.
+
Sort of, just it would be more verbose (as usual in [[Java]]). Instead the ''Listable'' [[trait]] one needs to define a [[Java]] '''interface''' with setters and getters for the ''next'' and ''prev'' properties. Everyone would then have to implement bodies of these methods again and again. With [[Scala]] [[trait]] one's gets that for free (and moreover the access is properly encapsulated). The ''List'' implementation would basically remain the same - the [[Java]] type mechanism is as powerful as [[Scala]]'s in this respect.
== Can this be done in [[C++]]? ==
== Can this be done in [[C++]]? ==
One question remains: Can this be emulated in [[C++]]? Mixins are inherently present in [[C++]] as the language supports multiple inheritance. Implicit conversions are indeed there. The only question is whether one can type this correctly without using casts. My early 90ties knowledge of [[C++]] would suggest, one needs casts, but maybe the [[C++]] changed and improved meanwhile. Anyone knows?
One question remains: Can this be emulated in [[C++]]? Mixins are inherently present in [[C++]] as the language supports multiple inheritance. Implicit conversions are indeed there. The only question is whether one can type this correctly without using casts. My early 90ties knowledge of [[C++]] would suggest, one needs casts, but maybe the [[C++]] changed and improved meanwhile. Anyone knows?

JaroslavTulach at 23:49, 2 September 2012 - 2012-09-02 23:49:54

←Older revision Revision as of 23:49, 2 September 2012
Line 37: Line 37:
== Can this be done in [[Java]]? ==
== Can this be done in [[Java]]? ==
-
Sort of, just is would be more verbose (as usual in [[Java]]). Instead the ''Listable'' [[trait]] one needs to define a [[Java]] '''interface''' with setters and getters for the ''next'' and ''prev'' properties. Everyone would then have to implement bodies of these methods again and again. With [[Scala]] [[trait]] one's gets that for free. The ''List'' implementation would basically remain the same - the [[Java]] type mechanism is as powerful as [[Scala]]'s in this respect.
+
Sort of, just it would be more verbose (as usual in [[Java]]). Instead the ''Listable'' [[trait]] one needs to define a [[Java]] '''interface''' with setters and getters for the ''next'' and ''prev'' properties. Everyone would then have to implement bodies of these methods again and again. With [[Scala]] [[trait]] one's gets that for free. The ''List'' implementation would basically remain the same - the [[Java]] type mechanism is as powerful as [[Scala]]'s in this respect.
== Can this be done in [[C++]]? ==
== Can this be done in [[C++]]? ==
One question remains: Can this be emulated in [[C++]]? Mixins are inherently present in [[C++]] as the language supports multiple inheritance. Implicit conversions are indeed there. The only question is whether one can type this correctly without using casts. My early 90ties knowledge of [[C++]] would suggest, one needs casts, but maybe the [[C++]] changed and improved meanwhile. Anyone knows?
One question remains: Can this be emulated in [[C++]]? Mixins are inherently present in [[C++]] as the language supports multiple inheritance. Implicit conversions are indeed there. The only question is whether one can type this correctly without using casts. My early 90ties knowledge of [[C++]] would suggest, one needs casts, but maybe the [[C++]] changed and improved meanwhile. Anyone knows?