Hi Stef,
On 17 Mar 2010, at 11:09, Stéphane Ducasse wrote:
On Mar 17, 2010, at 10:05 AM, Tudor Girba wrote:
Hi Stef,
On 17 Mar 2010, at 09:50, Stéphane Ducasse wrote:
On Mar 17, 2010, at 9:23 AM, Lukas Renggli wrote:
It tries to work with methods and classes through symbolic
names.. and
you immediately end up with
gemmorage of a need to keep separate 'core' and 'extension' ,
'meta'
and 'instance-side' methods in your model.
Yes, that's what I suggested, merge the extension and core
dictionaries.
I do not see how?
without first class class and no string match: '* class' ?
I'm curious
The issue is not between instance side and meta side. The issue is
with having two dictionaries for each: one for extensions and one
for definitions. If we have the information about which classes are
defined in this package, we only need to store the methods for the
class and we know which are extensions and which are not.
this is not that simple.
For each class I have to know the methods (defined | extended)
So I have to encode that information
why because not all the methods of a defined class are defined in a
package!
The class point defined in package graphics can be extended by
myPackage and these methods should not be part of the Graphics.
So I always need three information
Class * method * extended|defined
Not quite.
At this moment, for any given class in a package, you can either have
entries in the defined or in the extension dictionaries, but not in
both in the same time. So, this is an indication that you can simply
merge the two dictionaries.
As soon as you add a method to a package, you know exactly if that
method is defined or not by knowing whether the class is defined in
that package.
Also, if you do have the methods in one dictionary, then you also
won't have to care whether you moved the definition of a class between
packages. Right now, if you move the definition of a class without
touching the methods, you will have to ensure in the two packages that
the methods that were defined are not extensions and the other way
around. If you interpret the extension by looking at where the class
is defined, then you do not lose anything.
Yet another point is that I typically first want to know the methods
of a class from a package. I do not want to know which is extended or
which is not. So, I currently have to look it up in two dictionaries
which is not necessarily optimal.
Or am I missing something?
Cheers,
Doru
--
www.tudorgirba.com
"From an abstract enough point of view, any two things are similar."
_______________________________________________
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
