On 1 November 2013 03:36, Stéphane Ducasse stephane.duca...@inria.fr wrote:
On Oct 31, 2013, at 11:37 PM, Igor Stasenko siguc...@gmail.com 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
Hi Stef,
On Thu, Oct 31, 2013 at 6:49 PM, Stéphane Ducasse stephane.duca...@inria.fr
wrote:
On Oct 31, 2013, at 8:25 AM, Tudor Girba tu...@tudorgirba.com wrote:
I completely disagree with this point of view :).
We should assume an open world, not a close one. From this point of view,
This is not the same :)
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.
ah that yes but it will probably never happen in reality :)
I thought more about method extensions
Stef
I completely disagree with this point of view :).
We should assume an open world, not a close one. From this point of view,
any part of the system should be extensible by anyone. In most other
languages I know, it is not even possible to extend easily a class with new
functionality. In Pharo we
Basically here we discuss how to introduce in Pharo stateful class
extension and stateful traits. I like these features a lot because it means
I would be able to reuse the same class differently depending on the
context and the surrounding classes. But if we overuse that we will
definitely go into
Wow so much work to add an instance variable ?
In python is as simple as
MyClass.newVariable = 30
I always assumed Pharo was very similar.
On Thu, Oct 31, 2013 at 10:55 AM, Clément Bera bera.clem...@gmail.comwrote:
Basically here we discuss how to introduce in Pharo stateful class
On 31 Oct 2013, at 10:16, kilon alios kilon.al...@gmail.com wrote:
Wow so much work to add an instance variable ?
In python is as simple as
MyClass.newVariable = 30
I always assumed Pharo was very similar.
Reflectively it is that easy. It’s #addInstVarNamed:
But then the
On 31 Oct 2013, at 10:15, kilon alios kilon.al...@gmail.com wrote:
Wow so much work to add an instance variable ?
In python is as simple as
MyClass.newVariable = 30
I always assumed Pharo was very similar.
The discussion is about source code management.
Of course this is very easy
On 2013-10-31, at 09:55, Clément Bera bera.clem...@gmail.com wrote:
Basically here we discuss how to introduce in Pharo stateful class extension
and stateful traits. I like these features a lot because it means I would be
able to reuse the same class differently depending on the context and
I'm with Doru here, we already have the capability of extend completely the
system (not just to extend methods). Even if can be dangerous, that's a choice
of the user.
Our tools should empower the features of the language, not restrict them.
On Oct 31, 2013, at 7:49 AM, Camillo Bruni
On Oct 30, 2013, at 10:36 PM, Igor Stasenko siguc...@gmail.com wrote:
I don't think there's something to fix.
You cannot 'extend' classes belonging to other package in any other way
than adding extension methods.
Exact this was my conclusion too.
Allowing extension of ivars or any other
On 31 Oct 2013, at 18:12, Stéphane Ducasse stephane.duca...@inria.fr wrote:
On Oct 30, 2013, at 10:36 PM, Igor Stasenko siguc...@gmail.com wrote:
I don't think there's something to fix.
You cannot 'extend' classes belonging to other package in any other way
than adding extension methods.
On Oct 30, 2013, at 10:54 PM, Camillo Bruni camillobr...@gmail.com wrote:
On 2013-10-30, at 22:36, Igor Stasenko siguc...@gmail.com wrote:
I don't think there's something to fix.
You cannot 'extend' classes belonging to other package in any other way
than adding extension methods.
And you're going to bump into slot initialization order...
2013/10/31 Stéphane Ducasse stephane.duca...@inria.fr
On Oct 30, 2013, at 10:54 PM, Camillo Bruni camillobr...@gmail.com
wrote:
On 2013-10-30, at 22:36, Igor Stasenko siguc...@gmail.com wrote:
I don't think there's something
Unless initialization is lazy (and you arrange for avoiding/detecting
circular dependency)
2013/10/31 Nicolas Cellier nicolas.cellier.aka.n...@gmail.com
And you're going to bump into slot initialization order...
2013/10/31 Stéphane Ducasse stephane.duca...@inria.fr
On Oct 30, 2013, at
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 nicolas.cellier.aka.n...@gmail.com
Unless initialization is lazy (and you arrange for
On Oct 31, 2013, at 6:37 PM, Nicolas Cellier
nicolas.cellier.aka.n...@gmail.com wrote:
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 ;)
me too.
Same for ClassVariables they
On 31 October 2013 08:25, Tudor Girba tu...@tudorgirba.com wrote:
I completely disagree with this point of view :).
We should assume an open world, not a close one. From this point of view,
any part of the system should be extensible by anyone. In most other
languages I know, it is not even
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
On 31 October 2013 18:49, Stéphane Ducasse stephane.duca...@inria.frwrote:
On Oct 31, 2013, at 8:25 AM, Tudor Girba tu...@tudorgirba.com wrote:
I completely disagree with this point of view :).
We should assume an open world, not a close one. From this point of view,
any part of the system
I agree, on all you said.
But sometimes it's also interesting to push the concepts further and
explore their benefits/drawbacks before knowing exactly which problems they
will solve.
A researcher POV rather than an engineer one.
I'm an engineer, so I can play advocatus diaboli ;)
2013/10/31 Igor
On 31 October 2013 22:52, Nicolas Cellier
nicolas.cellier.aka.n...@gmail.com wrote:
I agree, on all you said.
But sometimes it's also interesting to push the concepts further and
explore their benefits/drawbacks before knowing exactly which problems they
will solve.
A researcher POV rather
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
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
On Oct 31, 2013, at 11:37 PM, Igor Stasenko siguc...@gmail.com 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
Ok in fact
Gisela forked the AST-Core package to be able to load a new version with the
instance variables.
Because there is no way to say that a class definition modification is attached
to a given package.
Stef
Apparently the problem is that gisela is adding instance variable to a class
I don't think there's something to fix.
You cannot 'extend' classes belonging to other package in any other way
than adding extension methods.
Allowing extension of ivars or any other vars by foreign package
is road to nowhere.
I would not like if shape of my kernel classes depends on what
27 matches
Mail list logo
