Re: [Brain-list] I am still alive ... :-) [LONG]

[Clemens H. <c.h...@gm...>]

Manuel Tomis writes:
> Hi Clemens

Hi Manuel,

(...)

> Anyway since my last mail, I have mostly been working on cleaning up
> and refactoring Brain.  Most of the stuff I changed are still not
> complete.

but we can see it evolving more and more ... :-)

> Right now I am working on Method lookup caches.  Also I will add the
> ability to have constant slots and private slots.  But this brings a
> problem of how to define them. It will not be fun to have a million
> methods like: foo final-private-method: #bla is: ...

(...)

> therefore we will not pollute the general object namespace, plus it
> can keep state between calls so that maybe we can say:
>   foo meta;
>     private  #! private will be remembered and will apply to below calls
>     method: .. is: ..;
>     method: .. is: ..;
>     public   #! public will also be remembered and apply to below calls
>     ....
> 
> But I am not sure yet. Ideas?

Hmmm ... it sounds a bit uncommon. But also promising and interesting. 
Perhaps try it out? Nothing that cannot be changed it it does not fit,
yes? But I would propose a more convenient name like 'slots' instead
of 'meta' to indicate, that we are dealing with object's slots right
now.

> I am still not sure how to handle conflicts when inheriting slots
> with the same name from different parents.

Perhaps I have an idea:

o I assume you will store the slot ids in a hashtable per object or
  so. Why not putting slots inherited by prototypes into a per
  prototype hashtable? So that if myobj has two prototypes it will
  have three hashtables one for every prototype and one for
  itself.

o All data slots and private methods would be stored into these per
  prototype hashtables. If a method of the prototype is invoked, it
  will look for data slots and private methods into the corresponding
  hashtable for that prototype. If a public method is called, it will
  look into the common hashtable.

o If I try to access a method of slot that is not in the common
  hashtable a left-to-right depth-first lookup will be performed.

o Of course it has not to be several hashtables but perhaps grouping
  within one hashtable would also be ok.

> Also lately I have been busting my head trying to find some way to
> have at least partial static type checking in brain. I am not yet

Please do not bother to much at first. I am sure we could add this
later. First Brain should work dynamically and then such typechecks
could be added.

(...)

> Also about iterators maybe instead of ListIterator, SetIterator I
> will have List Iterator, Set Iterator etc. But so far this is just a
> thought.

Sounds a good idea at the first glance. Try it!

(...)

> > Do that means we get the ':symbol' syntax instead of '#symbol'
> > one? It would really be more consistent to be able to build all
> > symbols in equal manner like :() instead of "()" to-symbol.
> When I first read your proposal I thought I liked it. But now after
> thinking about it some more I am not so sure any more. Basically my
> philosophy so far has been to keep the syntax extremely simple, but

I would not insisting on the meta parsing feature, but I still think I
would like to have :symbol instead of #symbol. It would be more
consistent as all symbols should be able to build then. () would not
being an exception then.

(...)

> have a negative meaning)). So right now I am thinking maybe we can
> keep your idea at the back of our heads, but not implement it yet
> until we come up with a really good use of it, and I make up my
> mind. What do you think?

Fine with me! But please consider to change #symbol --> :symbol
anyway.

(...)

> > o PROPOSAL: Signal-Slot concept
> ....
> Looks great!!! (Has been added to TODO queue) This is basically a
> more generic implementation of the Observer pattern, isn't it?

I have to confess that I do not know it. Unfortunately I never had
read that Design Pattern thingy. But it is still on *my* TODO list :-)

I have learned it using QT and I found it a great idea to encapsulate
objects that are only sending signals to communicate with the outer
world. If slots are connected, fine they will be called with
concerning arguments. If not, the signal emitting would go into the
emptyness! Also fine :-))))

And the best is, that a third component could connect the two other
objects then. And more than one slot could be connected to any given
signal. Great concept!

> > o Variables only assigned once in a scope? I think I have found an
> >   exception! I still like that behavior, but we should also think
> >   about this:
> The point is that shadowing a variable in an outer scope with one
> defined in an inner scope is a bad idea; instead one should give
> different names to different things. Can you give an example of
> where allowing it would be usefull?  (hmmm I just thought of one
> use: Shadowing builtin global objects (ex List,String,Monitor,
> Scope), so that if we add new ones we won't breaks programs that are
> unaware of them and use the same name, but this still does not
> justify allowing this for any scope, only for builtins)

After some thinking I feel you are right! Do not change current
behavior. It is more important to remain consistent. Also no
overloading of buildin, IMHO!

(...)

> > o Error during re-use of prototyped methods?
> > 
> >     s = "hello".
> >     s2 = Object new; 
> >       prototype-is: String;
> >       method: #greeting: is: { |a| (self + " " + a) println }.
>                                      ^^^^^^^^^^^
> The problem here is: self + " " self is not a string therefore the
> C++ method cannot use it as a string and concatenate it with " ".

I understand! But could we find a way to fake this. IMHO s2 should
behave like a String although it is not a String. Perhaps if prototype
is native one, a cloned copy should be stored together with the object
so that such messages could be send to the native object (a bit like
your old prototype concept of the old Brain)?

Just a quick thought! I do not know if it is a clever idea! But if it
is, that native object should be hidden and inaccessible from the
outside.

What do you think?

(...)

> statement :-).  The solution to this will have to be something
> (similar to Scope as you also say) like:

Would it be possible to simplify your idea to:

  { ... }
    if-error: { |exception|
      exception 
        on: foo do: bar;
        on: bla do: yada;
        ...
    }

That means that the exception could establish such a scope-like object
and handle the several on:do: messages?

BTW: We should try to decide whether Brain works with methods or
messages. I would vote for the last, whereas e.g. on:do: would be a
selector or message name.

(...)

> used...  or maybe not. I will think about the details and say
> more. Also I will add something like the 'finally' thingy in Java
> (probably called 'ensure:' as I think is the Smalltalk
> tradition). With the above solution we should still keep the old
> on:do: methods for maybe up to 4 handlers or something for
> convenience, but any more can be done with the above generic
> solution.

Give it a try ;-)

> I wish you Happy Holidays + any Seasonal Wishes that may apply ;-)

Thank you and same to you! :-)


> Manuel

Clemens.

-- 
Clemens Hintze  mailto: c.h...@gm...