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

[Manuel T. <ma...@sp...>]

Hi Clemens

I am really glad you are still there!!! :-)
But I understand that you were busy. Actually I was also kind of busy
with college projects, and that is why I have not achieved much progress with
Brain lately. My holidays are coming up, but it seems that
I will have to spend a large part of them finishing my college projects, and
therefore will not be able to dedicate all of them to fun and relaxing activities
like developing brain :-( But I hope to at least devote some days to Brain.

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.

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: ...
especially if in the future we find more kinds of attributes that a slot can have
(like maybe 'persistent' or who knows what). One solution I am thinking about
it to remove all the method:is: property:is: etc methods from all the objects and instead
add a method 'meta' that will return a MetaObject (something like an Iterator but for
slots, no relation to a Class or anything). So this meta object will have all the
slot manipulation methods and 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?

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

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 sure what restrictions
will be required to make such a thing possible, what kinds of syntax changes will
be necessary (for type annotations for example), or even what should be considered as a type,
if we can have type inference etc.
At the very least though I think that such mixed typing systems exist, for example
some Lisp/Scheme compilers. But this will not be done anytime soon in Brain if at all,
but I would appreciate any ideas on the subject. 

> And I also like your name changings to ThatStyle. Your changes to the
> exception handling are also very nice! Only that 'traits' is vanished
> makes me feeling a bit unease, IMO.
These may not be the final changes to the namespace. For example I am thinking
to put some related objects as slots of more general objects. For example
instead of having(these are not there yet so don't look for them :-) :
DatagramSocket ServerSocket etc I am thinking to have Socket Datagram, Socket Server etc.

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

Right now the global objects such as String/List/etc are what used to be in the traits.
This is so that you can create new stuff like: List new: 10 and at the same time be able to 
ask the 'type' of something like  (something is: List) in a convenient manner.
But things could still change if we find any better ways.

> > BTW. Do you think it is better to have one namespace for both
> > delegates and prototypes or should each of them have it's own
> > namespace?
> 
> I have thought long about this. I would tend to use only one namespace. 
> If I would have to select namespace every time would become tiresome
> would it?
After posting that I had a change of mind. I now think I will just have one
namespace per object, just like Self, and like you proposed, 
which will include slots/methods/prototypes/delegates/whatever.


> > > Do you remember, you want (probably) implementing the
> > > parser/compiler into Brain. Why not allow to install special
> > > handlers (written in Brain) that could handle arbitrary
> > > #... construct? How this?
> > After some thought I think I like your idea. Allthough the
> > Smalltalkish syntax of brain should be flexible enough for
> > expressing nice interfaces to a variety of things, we might aswell
> > provide a 'metaprogramming handler' feature like the one you
> > propose, for the sake of completeness and because sometimes it may
> > be usefull (but hopefully not overdone).
> 
> 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 very flexible and implement all
the features in the library. (your proposal of course is also part of the 'library',
but still it 'messes' with the syntax (please don't take the word 'messes' to 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?

> Mainly about how Brain works? What I have to pay attention to, to
> write extensions for Brain? How objects are builded? How is this all
> with Frame to be supposed to work with? How do I work together with
> the GC? ... All such things. A simply README file could be enough
> first. Not only for me as as beginner's guide for later guys joining
> us as well :-)

The only reason I have not written this yet (besides lazyness and relative lack of time)
is that I may do some changes to the object model and it's implementation, so I am
waiting a bit to finish the cleaning of the sources.
But as I said the HACKERS' GUIDE is coming soon to a theater near you.... :-)

> 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?

> 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)

> o Bug during IO?
<Still investigating...>

> 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 " ".

> o Consider to have special syntax for methods like on:do:on:do... to
>   avoid such really long and ugly names. I very like the solution you
>   have chosen for the scope object's when:do: method. Could we have
>   such for on:do: also?
> 
>     blk on: ... do: ... ;
>         on: ... do: ... .
I agree that it is ugly, but I don't like the idea to  make 'on:do:' 
be special syntactically (REASON: See above mentioned philosophy statement :-). 
The solution to this will have to be something (similar to Scope as you also say) like:

  {.....}   
    if-error:  #! this name fits with List at:if-error: and similar stuff
      (Handler new;
        on: foo do: bar;
        on: bla do: yada;
        ...
        ...
      )

Maybe a generic kind of object rather that a specific Handler can be 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.


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

Manuel