Traits do work nicely. What's your pain with them? (apart from the fact that the categorization in 2.0 is somewhat buggy)...
Phil On Mon, Dec 2, 2013 at 5:11 PM, Stéphane Ducasse <[email protected]>wrote: > > I’m not complaining that new tools are bad. I’m gust telling that I’d > prefer other ones in first place. E.i. old class browser running in a > separate thread instead of nautilus, > > But it was never like that. > The old browser is just worse code but the logic is the same. > > > tools for traits instead of slots > I do not understand what you mean because this is totally orthogonal. > > > etc… I’m not saying that slots are bad, no they are amazing. But traits > are powerful to but not widely used because we lack tools. > > Yes but not only :) > You see in PHP and perl they use them too. > > > The same bothers me with slots. Because we will need a tools for that, > and example with traits shows that we are not that good in it. > > Why? because we lack a nice metamodel (and we started to build ring for > that and it needs another iterations) > and a flexible way to build tool and not spaghetti code, > this is why we invested in Spec. > So > > > Once again, this is just my vision, and it seems to me that we are > building skyscraper on soil instead of creating a concrete base for it. > > LOL > We are doing infrastructure work since years. Just open your eyes to > realise it. > > FileSystem, > OPAL (imagine a new compiler) > New DebuggerModel, > Announcement, > AtomicQueue, > Cleaning morphic, > Spec, > Zinc > Better handling of rectangle > Better handling of layoutFrame > Better > better > better > > Do you want more look at the list of things we did: it is MASSIVE > MASSIVE and nearly only targeted at building > a strong and robust infrastructure. We just spent some time on > look but nothing compared to the rest. > > > Although you have more experience so maybe it’s better the way it is. > > > > uko > > > >> > >> > >>>>> Yes, This is a nice idea, but I was telling about the other thing. > It’s really simple to start a new process in Pharo. Maybe we should > introduce common practices in pharo? When I was following Obj-C course, one > of the fundamental thing that was taught: do time consuming tasks in the > other process. > >>>> > >>>> > >>>> forking processes is not a solution. because you can have shared > resources problems and updates and …. > >>> > >>> Yes, you risk races which could be tricky to find/debug. > >>> > >>> I'm **very** interested what's the solution you propose here? > >>> > >>> Jan > >>> > >>>> > >>>>> So I want to write a chapter on the concurrent programming in Pharo, > but is question is: am I missing something? Because this looks quite > trivial. > >>>>> > >>>>> Uko > >>>>> > >>>> > >>>> > >>>> > >>> > >>> > >> > >> > > > > > > >
