Or, you infer the right order, for example from the AST of each initializer you should be able to get the dependency graph... My own preference goes to laziness ;) 2013/10/31 Nicolas Cellier <[hidden email]>
|
On Oct 31, 2013, at 6:37 PM, Nicolas Cellier <[hidden email]> wrote:
Same for ClassVariables they should be totally self initializable without dependencies. Stef
|
In reply to this post by Tudor Girba-2
On Oct 31, 2013, at 8:25 AM, Tudor Girba <[hidden email]> wrote:
the runtime should be smart enough to recalculate objects shape.
|
In reply to this post by Tudor Girba-2
On 31 October 2013 08:25, Tudor Girba <[hidden email]> wrote:
it is doable, and easily, as others saying nothing prevents you from
saying SomeClass addInstvarNames: 'foo' but the problems in not extending per se, but how you manage it at source level? Like you said, we now having slots.. so then how you think a class definition may look like if some class has extension slots defined by other package? Object subclass: #Point slots: { x, y -> Kernel-Classes z -> ThirdPartyRandomExtensionPackage z -> SecondThirdPartyRandomExtensionPackage z -> ThirdThirdPartyRandomExtensionPackage } i am not against being open. i am against being open to opening can of worms ;) (Apart from completely inadequate proportion between effort to implement such feature and supporting it in many tools (MC etc) comparing to the actual/current need of having it). Clearly, there is no limits in complexity where we can go in attempt to describe our systems with metadata up to tiniest level of detail. Except from some real-world ones: - implementation effort - ease of learn & use - and at last.. sanity :)
-- Best regards, Igor Stasenko. |
Hehe, no problem, because any method from SecondThirdPartyRandomExtensio nPackage would know which z slot to use. Or if you insist on uniqueness, you can invent decorators like well known languages ;) It could get more complex if a FourthThirdPartyExtension would like to extend the second extension further and directly access this specific z slot ;)
2013/10/31 Igor Stasenko <[hidden email]>
|
In reply to this post by Stéphane Ducasse
On 31 October 2013 18:49, Stéphane Ducasse <[hidden email]> wrote:
and run into conflict with each and every use of instance where it implies that it has certain shape (or state) but not the other one. IMO, extending original class is anti-modular. It is global, thus anti-modular by definition. I would much more prefer instead of saying: Package A is: { extends: Object withSlot: x } saying: in scope of Package A {
Object instances i creating has extra slot: x } because when you making extension to class globally visible, while nobody else is aware of (because it comes only with your package you just loaded), this brings nothing but just problems on many different levels. Aside there's much wiser path (imo), how you can 'extend' the state: by either subclassing or delegation/wrapping/decoration, which helps to clearly separate between what is yours and what is not.
-- Best regards, Igor Stasenko. |
In reply to this post by Nicolas Cellier
On 31 October 2013 22:37, Nicolas Cellier <[hidden email]> wrote:
like i said, we can invent anything, put many workaround and/or conflict-resolution rules. The main question is it really worth it? We can endlessly theorize, how to put such thing and what should be done/changed, but first i need a compelling reason, clearly showing the advantage of having it. So far, i can only see, that it will bring more problems than solve. I am in favor of KISS, unless there is big and apparent wins in having extra complexity.
-- Best regards, Igor Stasenko. |
I agree, on all you said. A researcher POV rather than an engineer one.But sometimes it's also interesting to push the concepts further and explore their benefits/drawbacks before knowing exactly which problems they will solve. I'm an engineer, so I can play advocatus diaboli ;) 2013/10/31 Igor Stasenko <[hidden email]>
|
On 31 October 2013 22:52, Nicolas Cellier <[hidden email]> wrote:
ah, don't worry, i am myself sometimes like to think in such mode: 'what if...' 'it would be nice to try .. ' but certainly when its about addind/changing something in existing system (not just experiment), my main rule is to see how new idea could help to simplify the system, in terms of less code, cleaner design and less effort to implement. What i see in proposed one is straightly opposite to that. There's an infinite ways how you can draw a line on white board (and which tools you using to do that).. but i doubt you can invent something simpler and easier than using pen and own hand.
-- Best regards, Igor Stasenko. |
define the format of key/value dictionary and add primitives to retrieve and store key-based properties for objects. What i like in it, that at language side it is cost nothing: you don't have to extend
the language to formally define the slots (but you may, of course), and there's nothing preventing you from using private keys and not giving them away to anyone to keep your data private and not exposing it globally (except from reflection tools i guess). And, what is important, you are free to use them or not.. and it costs almost nothing in terms of performance, and nothing in terms of formalism and extra rules in language/package/source management etc etc -- Best regards, Igor Stasenko. |
In reply to this post by Igor Stasenko
The problem is that control version system just save text not text and meta data because a package could have a class definition + in our case a instance variable addition object Now we just save text so this is why we are in trouble. Again this is a text-oriented diff way of the world and this is poor. Stef
|
In reply to this post by Igor Stasenko
On Oct 31, 2013, at 11:37 PM, Igor Stasenko <[hidden email]> wrote: > > Btw, if you remember, i already proposed how to solve 'extending object's state with arbitrary state' , mainly by changing the object format to support variable number of key-value properties per object. > Similar to javascript or self, where you can define a new property on a per-object basis. > This is fairly easy to implement, at VM level, just reserve extra field in object format, > define the format of key/value dictionary and add primitives to retrieve and store key-based properties for objects. > What i like in it, that at language side it is cost nothing: you don't have to extend > the language to formally define the slots (but you may, of course), > and there's nothing preventing you from using private keys and not giving them away > to anyone to keep your data private and not exposing it globally (except from reflection tools i guess). > And, what is important, you are free to use them or not.. and it costs almost nothing in terms of performance, and nothing in terms of formalism and extra rules in language/package/source management etc etc you do not need to be at the object level. For me this would be another level of mess. When you think about class extensions we get them because methods are not in the scope of the their class so it was easy to define a method into a file that represented another changeset. Now we have problem with iv extensions because they are scoped by the class definition. Stef > > -- > Best regards, > Igor Stasenko. > |
On 1 November 2013 03:36, Stéphane Ducasse <[hidden email]> wrote:
> > On Oct 31, 2013, at 11:37 PM, Igor Stasenko <[hidden email]> wrote: > >> >> Btw, if you remember, i already proposed how to solve 'extending object's state with arbitrary state' , mainly by changing the object format to support variable number of key-value properties per object. >> Similar to javascript or self, where you can define a new property on a per-object basis. >> This is fairly easy to implement, at VM level, just reserve extra field in object format, >> define the format of key/value dictionary and add primitives to retrieve and store key-based properties for objects. >> What i like in it, that at language side it is cost nothing: you don't have to extend >> the language to formally define the slots (but you may, of course), >> and there's nothing preventing you from using private keys and not giving them away >> to anyone to keep your data private and not exposing it globally (except from reflection tools i guess). >> And, what is important, you are free to use them or not.. and it costs almost nothing in terms of performance, and nothing in terms of formalism and extra rules in language/package/source management etc etc > > you do not need to be at the object level. For me this would be another level of mess. > > When you think about class extensions we get them because methods are not in the scope of the their class > so it was easy to define a method into a file that represented another changeset. > Now we have problem with iv extensions because they are scoped by the class definition. Does this imply that the correct scope for a class extension would be per package? Say package Base defines a class Foo and package Ext adds a slot to Foo, could you model this through an (Squeak) Environment-like way like this?: In your application's Environment Env, Foo is as it's defined by the Base package. When you load Foo into Env, Env stores a _subclass_ of Foo Foo1, adding the slot to Foo1. But Env actually maps Foo1 to Foo. Within Env, looking up "Foo" means finding Foo1, with the extension. In any other Environment, looking up "Foo" finds Foo, without the extension. (This is how I think extending classes with methods should work too, but I'll be the first to admit that this idea is a "what if we..." idea without any real thought into how feasible it is.) frank > Stef >> >> -- >> Best regards, >> Igor Stasenko. >> > > |
In reply to this post by Stéphane Ducasse
I agree. I do not see why we make the situation so complicated. Extending a class with state is the same conceptually as is extending it with methods. The same type of problems apply. We can extend a class with methods, and we know it is powerful.
Yes, you can have problems with overrides sometimes, but in practice, method extensions collision occurs rarely now. With a little discipline, you can get things to work quite nicely. And again, it is the responsibility of the extender to manage the extensions.
Doru On Fri, Nov 1, 2013 at 4:36 AM, Stéphane Ducasse <[hidden email]> wrote:
"Every thing has its own flow"
|
In reply to this post by Stéphane Ducasse
Hi Stef,
On Thu, Oct 31, 2013 at 6:49 PM, Stéphane Ducasse <[hidden email]> wrote:
What is not the same? :) By "override" I meant the problem induced by two packages that define the same method, and that are being loaded at the same time.
Cheers, Doru
"Every thing has its own flow"
|
ah that yes but it will probably never happen in reality :) I thought more about method extensions Stef |
Free forum by Nabble | Edit this page |