Old ClassBuilder remove!
Hi, Yesterday Camille did the change to finally remove the old class builder! (just a removal + a small change to NativeBoost to use the new class builder to create anonymous classes). This means - 1000 Loc of completely un-understandable code removed. - we now 100% run on the new class builder from the Slot Project. Next on the list (not all for Pharo3): - remove PackageInfo - old Browser + CodeHolder hierarchy - PseudoClass&Co â> Ring - old AST+Compiler (this in Pharo4) We already did (all in Pharo3): -> remove URI -> deprecated Url for ZnUrl -> removed HTTPSocket facade -> MIMEType retired for ZnMimeType -> old Debugger is removed -> Class categories are replaced by Protocols I am quite sure that these cleanups will enable us to build a lot of very interesting things in the future. Marcus
wow, impressive! On Thu, Nov 21, 2013 at 9:02 AM, Marcus Denker <marcus.denker@inria.fr>wrote:
Hi,
Yesterday Camille did the change to finally remove the old class builder! (just a removal + a small change to NativeBoost to use the new class builder to create anonymous classes).
This means - 1000 Loc of completely un-understandable code removed. - we now 100% run on the new class builder from the Slot Project.
Next on the list (not all for Pharo3):
- remove PackageInfo - old Browser + CodeHolder hierarchy - PseudoClass&Co â> Ring - old AST+Compiler (this in Pharo4)
We already did (all in Pharo3): -> remove URI -> deprecated Url for ZnUrl -> removed HTTPSocket facade -> MIMEType retired for ZnMimeType -> old Debugger is removed -> Class categories are replaced by Protocols
I am quite sure that these cleanups will enable us to build a lot of very interesting things in the future.
Marcus
Triple impressive! This is another sample of an apparently tiny change that actually has deep impact on the future of our beloved environment. Ladies and gentlemen, I know you are busy, but please take the time to acknowledge it :) Doru On Thu, Nov 21, 2013 at 12:58 PM, Martin Dias <tinchodias@gmail.com> wrote:
wow, impressive!
On Thu, Nov 21, 2013 at 9:02 AM, Marcus Denker <marcus.denker@inria.fr>wrote:
Hi,
Yesterday Camille did the change to finally remove the old class builder! (just a removal + a small change to NativeBoost to use the new class builder to create anonymous classes).
This means - 1000 Loc of completely un-understandable code removed. - we now 100% run on the new class builder from the Slot Project.
Next on the list (not all for Pharo3):
- remove PackageInfo - old Browser + CodeHolder hierarchy - PseudoClass&Co â> Ring - old AST+Compiler (this in Pharo4)
We already did (all in Pharo3): -> remove URI -> deprecated Url for ZnUrl -> removed HTTPSocket facade -> MIMEType retired for ZnMimeType -> old Debugger is removed -> Class categories are replaced by Protocols
I am quite sure that these cleanups will enable us to build a lot of very interesting things in the future.
Marcus
-- www.tudorgirba.com "Every thing has its own flow"
any links why newcomers like me should be impressed ? Whats the advantages ? On Thu, Nov 21, 2013 at 2:21 PM, Tudor Girba <tudor@tudorgirba.com> wrote:
Triple impressive! This is another sample of an apparently tiny change that actually has deep impact on the future of our beloved environment.
Ladies and gentlemen, I know you are busy, but please take the time to acknowledge it :)
Doru
On Thu, Nov 21, 2013 at 12:58 PM, Martin Dias <tinchodias@gmail.com>wrote:
wow, impressive!
On Thu, Nov 21, 2013 at 9:02 AM, Marcus Denker <marcus.denker@inria.fr>wrote:
Hi,
Yesterday Camille did the change to finally remove the old class builder! (just a removal + a small change to NativeBoost to use the new class builder to create anonymous classes).
This means - 1000 Loc of completely un-understandable code removed. - we now 100% run on the new class builder from the Slot Project.
Next on the list (not all for Pharo3):
- remove PackageInfo - old Browser + CodeHolder hierarchy - PseudoClass&Co â> Ring - old AST+Compiler (this in Pharo4)
We already did (all in Pharo3): -> remove URI -> deprecated Url for ZnUrl -> removed HTTPSocket facade -> MIMEType retired for ZnMimeType -> old Debugger is removed -> Class categories are replaced by Protocols
I am quite sure that these cleanups will enable us to build a lot of very interesting things in the future.
Marcus
-- www.tudorgirba.com
"Every thing has its own flow"
On 21 nov. 2013, at 13:44, kilon alios <kilon.alios@gmail.com> wrote:
any links why newcomers like me should be impressed ? Whats the advantages ?
That's just cleaning. The old class builder was an incredibly complex piece of code that is now replaced with the Slot class builder. The later is based on slots and is much more understandable and thus much easier to maintain. It's been integrated some time ago thanks to Martin. Slots are the work of Toon and Camillo and enables a lot of useful features: http://rmod.lille.inria.fr/archives/papers/Verw11a-OOSPLA11-FlexibleObjectLa... They are based on the reification of class layouts (variable,weak,fixed and co) and instance variables (slots). Slots are an abstraction added on top of low-level class "fields". It means that one will be able to create a customized slot class that define the logic to read and write a slot: Object subclass: #MyClass slots: { x => MyFancySlot } category: 'Playground' Then when a method read or writes x, the logic you defined in MyFancySlot is executed. All that still need to be absorbed by Opal so it's not available right now but it will (Pharo 4)!
On Thu, Nov 21, 2013 at 2:21 PM, Tudor Girba <tudor@tudorgirba.com> wrote: Triple impressive! This is another sample of an apparently tiny change that actually has deep impact on the future of our beloved environment.
Ladies and gentlemen, I know you are busy, but please take the time to acknowledge it :)
Doru
On Thu, Nov 21, 2013 at 12:58 PM, Martin Dias <tinchodias@gmail.com> wrote: wow, impressive!
On Thu, Nov 21, 2013 at 9:02 AM, Marcus Denker <marcus.denker@inria.fr> wrote: Hi,
Yesterday Camille did the change to finally remove the old class builder! (just a removal + a small change to NativeBoost to use the new class builder to create anonymous classes).
This means - 1000 Loc of completely un-understandable code removed. - we now 100% run on the new class builder from the Slot Project.
Next on the list (not all for Pharo3):
- remove PackageInfo - old Browser + CodeHolder hierarchy - PseudoClass&Co â> Ring - old AST+Compiler (this in Pharo4)
We already did (all in Pharo3): -> remove URI -> deprecated Url for ZnUrl -> removed HTTPSocket facade -> MIMEType retired for ZnMimeType -> old Debugger is removed -> Class categories are replaced by Protocols
I am quite sure that these cleanups will enable us to build a lot of very interesting things in the future.
Marcus
-- www.tudorgirba.com
"Every thing has its own flow"
facking awesome ! On Thursday, November 21, 2013, Camille Teruel wrote:
On 21 nov. 2013, at 13:44, kilon alios <kilon.alios@gmail.com<javascript:_e({}, 'cvml', 'kilon.alios@gmail.com');>> wrote: A
any links why newcomers like me should be impressed ? Whats the advantages ?
That's just cleaning. The old class builder was an incredibly complex piece of code that is now replaced with the Slot class builder. The later is based on slots and is much more understandable and thus much easier to maintain. It's been integrated some time ago thanks to Martin.
Slots are the work of Toon and Camillo and enables a lot of useful features:
http://rmod.lille.inria.fr/archives/papers/Verw11a-OOSPLA11-FlexibleObjectLa... They are based on the reification of class layouts (variable,weak,fixed and co) and instance variables (slots). Slots are an abstraction added on top of low-level class "fields". It means that one will be able to create a customized slot class that define the logic to read and write a slot:
Object subclass: #MyClass slots: { x => MyFancySlot } category: 'Playground'
Then when a method read or writes x, the logic you defined in MyFancySlot is executed. All that still need to be absorbed by Opal so it's not available right now but it will (Pharo 4)!
On Thu, Nov 21, 2013 at 2:21 PM, Tudor Girba <tudor@tudorgirba.com<javascript:_e({}, 'cvml', 'tudor@tudorgirba.com');>
wrote:
Triple impressive! This is another sample of an apparently tiny change that actually has deep impact on the future of our beloved environment.
Ladies and gentlemen, I know you are busy, but please take the time to acknowledge it :)
Doru
On Thu, Nov 21, 2013 at 12:58 PM, Martin Dias <tinchodias@gmail.com<javascript:_e({}, 'cvml', 'tinchodias@gmail.com');>
wrote:
wow, impressive!
On Thu, Nov 21, 2013 at 9:02 AM, Marcus Denker <marcus.denker@inria.fr<javascript:_e({}, 'cvml', 'marcus.denker@inria.fr');>
wrote:
Hi,
Yesterday Camille did the change to finally remove the old class builder! (just a removal + a small change to NativeBoost to use the new class builder to create anonymous classes).
This means - 1000 Loc of completely un-understandable code removed. - we now 100% run on the new class builder from the Slot Project.
Next on the list (not all for Pharo3):
- remove PackageInfo - old Browser + CodeHolder hierarchy - PseudoClass&Co â> Ring - old AST+Compiler (this in Pharo4)
We already did (all in Pharo3): -> remove URI -> deprecated Url for ZnUrl -> removed HTTPSocket facade -> MIMEType retired for ZnMimeType -> old Debugger is removed -> Class categories are replaced by Protocols
I am quite sure that these cleanups will enable us to build a lot of very interesting things in the future.
Marcus
-- www.tudorgirba.com
"Every thing has its own flow"
-- --- Philippe Back Dramatic Performance Improvements Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail:phil@highoctane.be | Web: http://philippeback.eu Blog: http://philippeback.be | Twitter: @philippeback Youtube: http://www.youtube.com/user/philippeback/videos High Octane SPRL rue cour Boisacq 101 | 1301 Bierges | Belgium Pharo Consortium Member - http://consortium.pharo.org/ Featured on the Software Process and Measurement Cast - http://spamcast.libsyn.com Sparx Systems Enterprise Architect and Ability Engineering EADocX Value Added Reseller
yes thanks a lot! I like cleaning. #Luc 2013/11/21 Camille Teruel <camille.teruel@gmail.com>
On 21 nov. 2013, at 13:44, kilon alios <kilon.alios@gmail.com> wrote:
any links why newcomers like me should be impressed ? Whats the advantages ?
That's just cleaning. The old class builder was an incredibly complex piece of code that is now replaced with the Slot class builder. The later is based on slots and is much more understandable and thus much easier to maintain. It's been integrated some time ago thanks to Martin.
Slots are the work of Toon and Camillo and enables a lot of useful features:
http://rmod.lille.inria.fr/archives/papers/Verw11a-OOSPLA11-FlexibleObjectLa... They are based on the reification of class layouts (variable,weak,fixed and co) and instance variables (slots). Slots are an abstraction added on top of low-level class "fields". It means that one will be able to create a customized slot class that define the logic to read and write a slot:
Object subclass: #MyClass slots: { x => MyFancySlot } category: 'Playground'
Then when a method read or writes x, the logic you defined in MyFancySlot is executed. All that still need to be absorbed by Opal so it's not available right now but it will (Pharo 4)!
On Thu, Nov 21, 2013 at 2:21 PM, Tudor Girba <tudor@tudorgirba.com> wrote:
Triple impressive! This is another sample of an apparently tiny change that actually has deep impact on the future of our beloved environment.
Ladies and gentlemen, I know you are busy, but please take the time to acknowledge it :)
Doru
On Thu, Nov 21, 2013 at 12:58 PM, Martin Dias <tinchodias@gmail.com>wrote:
wow, impressive!
On Thu, Nov 21, 2013 at 9:02 AM, Marcus Denker <marcus.denker@inria.fr>wrote:
Hi,
Yesterday Camille did the change to finally remove the old class builder! (just a removal + a small change to NativeBoost to use the new class builder to create anonymous classes).
This means - 1000 Loc of completely un-understandable code removed. - we now 100% run on the new class builder from the Slot Project.
Next on the list (not all for Pharo3):
- remove PackageInfo - old Browser + CodeHolder hierarchy - PseudoClass&Co â> Ring - old AST+Compiler (this in Pharo4)
We already did (all in Pharo3): -> remove URI -> deprecated Url for ZnUrl -> removed HTTPSocket facade -> MIMEType retired for ZnMimeType -> old Debugger is removed -> Class categories are replaced by Protocols
I am quite sure that these cleanups will enable us to build a lot of very interesting things in the future.
Marcus
-- www.tudorgirba.com
"Every thing has its own flow"
Hi, This is not *just cleaning*! You might perceive it as such being so involved in it. You guys replaced something ugly with something based on a sound explicit model. When you do this at such a core level, the possibilities explode two layers on top. You might just do not see it, yet :). Just two examples: - Morphic uses a dictionary to allow extensions to add attributes to the base class. This is closed-world-based-assumption thinking because I have to know in advance what parts will be extended by someone else. This should be easily changeable with slots given that slots are manipulate-able at runtime (ideally). - In Fame we implement bidirectional relationships. By bidirectional relationships I mean you have classes like A ->* B, and when you have a B object and set the A parent, it automatically adds the B instance to the collection in A. The current implementation in Fame is difficult to grasp and the code of specifying the slots is spread over the whole Moose models. Once slots are supported as first class, we can build the strategy of bidirectionality directly in the slot support. This will be more elegant. Doru On Thu, Nov 21, 2013 at 2:24 PM, Camille Teruel <camille.teruel@gmail.com>wrote:
On 21 nov. 2013, at 13:44, kilon alios <kilon.alios@gmail.com> wrote:
any links why newcomers like me should be impressed ? Whats the advantages ?
That's just cleaning. The old class builder was an incredibly complex piece of code that is now replaced with the Slot class builder. The later is based on slots and is much more understandable and thus much easier to maintain. It's been integrated some time ago thanks to Martin.
Slots are the work of Toon and Camillo and enables a lot of useful features:
http://rmod.lille.inria.fr/archives/papers/Verw11a-OOSPLA11-FlexibleObjectLa... They are based on the reification of class layouts (variable,weak,fixed and co) and instance variables (slots). Slots are an abstraction added on top of low-level class "fields". It means that one will be able to create a customized slot class that define the logic to read and write a slot:
Object subclass: #MyClass slots: { x => MyFancySlot } category: 'Playground'
Then when a method read or writes x, the logic you defined in MyFancySlot is executed. All that still need to be absorbed by Opal so it's not available right now but it will (Pharo 4)!
On Thu, Nov 21, 2013 at 2:21 PM, Tudor Girba <tudor@tudorgirba.com> wrote:
Triple impressive! This is another sample of an apparently tiny change that actually has deep impact on the future of our beloved environment.
Ladies and gentlemen, I know you are busy, but please take the time to acknowledge it :)
Doru
On Thu, Nov 21, 2013 at 12:58 PM, Martin Dias <tinchodias@gmail.com>wrote:
wow, impressive!
On Thu, Nov 21, 2013 at 9:02 AM, Marcus Denker <marcus.denker@inria.fr>wrote:
Hi,
Yesterday Camille did the change to finally remove the old class builder! (just a removal + a small change to NativeBoost to use the new class builder to create anonymous classes).
This means - 1000 Loc of completely un-understandable code removed. - we now 100% run on the new class builder from the Slot Project.
Next on the list (not all for Pharo3):
- remove PackageInfo - old Browser + CodeHolder hierarchy - PseudoClass&Co â> Ring - old AST+Compiler (this in Pharo4)
We already did (all in Pharo3): -> remove URI -> deprecated Url for ZnUrl -> removed HTTPSocket facade -> MIMEType retired for ZnMimeType -> old Debugger is removed -> Class categories are replaced by Protocols
I am quite sure that these cleanups will enable us to build a lot of very interesting things in the future.
Marcus
-- www.tudorgirba.com
"Every thing has its own flow"
-- www.tudorgirba.com "Every thing has its own flow"
And then, imagine what this will do for tools. Given that the class instance will know what kind of slots are around, the tools can help you manage them. You will be able to build your class and then simply say that you want a slot to be bidirrectional and point it to the opposite slot. Really, I am so excited :) Doru On Thu, Nov 21, 2013 at 2:45 PM, Tudor Girba <tudor@tudorgirba.com> wrote:
Hi,
This is not *just cleaning*! You might perceive it as such being so involved in it. You guys replaced something ugly with something based on a sound explicit model.
When you do this at such a core level, the possibilities explode two layers on top. You might just do not see it, yet :).
Just two examples: - Morphic uses a dictionary to allow extensions to add attributes to the base class. This is closed-world-based-assumption thinking because I have to know in advance what parts will be extended by someone else. This should be easily changeable with slots given that slots are manipulate-able at runtime (ideally). - In Fame we implement bidirectional relationships. By bidirectional relationships I mean you have classes like A ->* B, and when you have a B object and set the A parent, it automatically adds the B instance to the collection in A. The current implementation in Fame is difficult to grasp and the code of specifying the slots is spread over the whole Moose models. Once slots are supported as first class, we can build the strategy of bidirectionality directly in the slot support. This will be more elegant.
Doru
On Thu, Nov 21, 2013 at 2:24 PM, Camille Teruel <camille.teruel@gmail.com>wrote:
On 21 nov. 2013, at 13:44, kilon alios <kilon.alios@gmail.com> wrote:
any links why newcomers like me should be impressed ? Whats the advantages ?
That's just cleaning. The old class builder was an incredibly complex piece of code that is now replaced with the Slot class builder. The later is based on slots and is much more understandable and thus much easier to maintain. It's been integrated some time ago thanks to Martin.
Slots are the work of Toon and Camillo and enables a lot of useful features:
http://rmod.lille.inria.fr/archives/papers/Verw11a-OOSPLA11-FlexibleObjectLa... They are based on the reification of class layouts (variable,weak,fixed and co) and instance variables (slots). Slots are an abstraction added on top of low-level class "fields". It means that one will be able to create a customized slot class that define the logic to read and write a slot:
Object subclass: #MyClass slots: { x => MyFancySlot } category: 'Playground'
Then when a method read or writes x, the logic you defined in MyFancySlot is executed. All that still need to be absorbed by Opal so it's not available right now but it will (Pharo 4)!
On Thu, Nov 21, 2013 at 2:21 PM, Tudor Girba <tudor@tudorgirba.com>wrote:
Triple impressive! This is another sample of an apparently tiny change that actually has deep impact on the future of our beloved environment.
Ladies and gentlemen, I know you are busy, but please take the time to acknowledge it :)
Doru
On Thu, Nov 21, 2013 at 12:58 PM, Martin Dias <tinchodias@gmail.com>wrote:
wow, impressive!
On Thu, Nov 21, 2013 at 9:02 AM, Marcus Denker <marcus.denker@inria.fr>wrote:
Hi,
Yesterday Camille did the change to finally remove the old class builder! (just a removal + a small change to NativeBoost to use the new class builder to create anonymous classes).
This means - 1000 Loc of completely un-understandable code removed. - we now 100% run on the new class builder from the Slot Project.
Next on the list (not all for Pharo3):
- remove PackageInfo - old Browser + CodeHolder hierarchy - PseudoClass&Co â> Ring - old AST+Compiler (this in Pharo4)
We already did (all in Pharo3): -> remove URI -> deprecated Url for ZnUrl -> removed HTTPSocket facade -> MIMEType retired for ZnMimeType -> old Debugger is removed -> Class categories are replaced by Protocols
I am quite sure that these cleanups will enable us to build a lot of very interesting things in the future.
Marcus
-- www.tudorgirba.com
"Every thing has its own flow"
-- www.tudorgirba.com
"Every thing has its own flow"
-- www.tudorgirba.com "Every thing has its own flow"
On Nov 21, 2013, at 2:49 PM, Tudor Girba <tudor@tudorgirba.com> wrote:
And then, imagine what this will do for tools. Given that the class instance will know what kind of slots are around, the tools can help you manage them. You will be able to build your class and then simply say that you want a slot to be bidirrectional and point it to the opposite slot. Really, I am so excited :)
We are in sync :) I'm curious to understand/build the API of collabation between class <-> slot and opal for such example
On 21 nov. 2013, at 14:45, Tudor Girba <tudor@tudorgirba.com> wrote:
Hi,
This is not *just cleaning*!
I wasn't talking about the creation of the slot model nor its integration in the image, but about killing the old class builder, a really enjoyable moment BTW :)
You might perceive it as such being so involved in it. You guys replaced something ugly with something based on a sound explicit model. When you do this at such a core level, the possibilities explode two layers on top. You might just do not see it, yet :).
Just two examples: - Morphic uses a dictionary to allow extensions to add attributes to the base class. This is closed-world-based-assumption thinking because I have to know in advance what parts will be extended by someone else. This should be easily changeable with slots given that slots are manipulate-able at runtime (ideally). - In Fame we implement bidirectional relationships. By bidirectional relationships I mean you have classes like A ->* B, and when you have a B object and set the A parent, it automatically adds the B instance to the collection in A. The current implementation in Fame is difficult to grasp and the code of specifying the slots is spread over the whole Moose models. Once slots are supported as first class, we can build the strategy of bidirectionality directly in the slot support. This will be more elegant.
Doru
On Thu, Nov 21, 2013 at 2:24 PM, Camille Teruel <camille.teruel@gmail.com> wrote:
On 21 nov. 2013, at 13:44, kilon alios <kilon.alios@gmail.com> wrote:
any links why newcomers like me should be impressed ? Whats the advantages ?
That's just cleaning. The old class builder was an incredibly complex piece of code that is now replaced with the Slot class builder. The later is based on slots and is much more understandable and thus much easier to maintain. It's been integrated some time ago thanks to Martin.
Slots are the work of Toon and Camillo and enables a lot of useful features: http://rmod.lille.inria.fr/archives/papers/Verw11a-OOSPLA11-FlexibleObjectLa... They are based on the reification of class layouts (variable,weak,fixed and co) and instance variables (slots). Slots are an abstraction added on top of low-level class "fields". It means that one will be able to create a customized slot class that define the logic to read and write a slot:
Object subclass: #MyClass slots: { x => MyFancySlot } category: 'Playground'
Then when a method read or writes x, the logic you defined in MyFancySlot is executed. All that still need to be absorbed by Opal so it's not available right now but it will (Pharo 4)!
On Thu, Nov 21, 2013 at 2:21 PM, Tudor Girba <tudor@tudorgirba.com> wrote: Triple impressive! This is another sample of an apparently tiny change that actually has deep impact on the future of our beloved environment.
Ladies and gentlemen, I know you are busy, but please take the time to acknowledge it :)
Doru
On Thu, Nov 21, 2013 at 12:58 PM, Martin Dias <tinchodias@gmail.com> wrote: wow, impressive!
On Thu, Nov 21, 2013 at 9:02 AM, Marcus Denker <marcus.denker@inria.fr> wrote: Hi,
Yesterday Camille did the change to finally remove the old class builder! (just a removal + a small change to NativeBoost to use the new class builder to create anonymous classes).
This means - 1000 Loc of completely un-understandable code removed. - we now 100% run on the new class builder from the Slot Project.
Next on the list (not all for Pharo3):
- remove PackageInfo - old Browser + CodeHolder hierarchy - PseudoClass&Co â> Ring - old AST+Compiler (this in Pharo4)
We already did (all in Pharo3): -> remove URI -> deprecated Url for ZnUrl -> removed HTTPSocket facade -> MIMEType retired for ZnMimeType -> old Debugger is removed -> Class categories are replaced by Protocols
I am quite sure that these cleanups will enable us to build a lot of very interesting things in the future.
Marcus
-- www.tudorgirba.com
"Every thing has its own flow"
-- www.tudorgirba.com
"Every thing has its own flow"
Just two examples: - Morphic uses a dictionary to allow extensions to add attributes to the base class. This is closed-world-based-assumption thinking because I have to know in advance what parts will be extended by someone else. This should be easily changeable with slots given that slots are manipulate-able at runtime (ideally).
Since I have several classes that inherit from a superclass that provides a property-dictionary, I'm interested to better understand what you mean by needing to know in advance what parts will be extended by someone else?
Hi Chris, The dictionary had to be added in the Morphic class by whoever developed Morphic so that you can extend it. That means that they had to predict that you will extend it. Imagine that they wouldn't have predicted that. We would simply not be able to extend Morphic. Contrast this situation with methods defined in a class. In this case, the language provides us with the ability of extending any class with extra methods. This is a powerful mechanism that we take for granted. We need to approach in the same way all constructs in the language, including instance variables and traits definitions. Slots should solve the instance variables problem. Cheers, Doru
+ 1000 I want relationship using Slot :) Stef On Nov 21, 2013, at 2:45 PM, Tudor Girba <tudor@tudorgirba.com> wrote:
Hi,
This is not *just cleaning*! You might perceive it as such being so involved in it. You guys replaced something ugly with something based on a sound explicit model.
When you do this at such a core level, the possibilities explode two layers on top. You might just do not see it, yet :).
Just two examples: - Morphic uses a dictionary to allow extensions to add attributes to the base class. This is closed-world-based-assumption thinking because I have to know in advance what parts will be extended by someone else. This should be easily changeable with slots given that slots are manipulate-able at runtime (ideally). - In Fame we implement bidirectional relationships. By bidirectional relationships I mean you have classes like A ->* B, and when you have a B object and set the A parent, it automatically adds the B instance to the collection in A. The current implementation in Fame is difficult to grasp and the code of specifying the slots is spread over the whole Moose models. Once slots are supported as first class, we can build the strategy of bidirectionality directly in the slot support. This will be more elegant.
Doru
On Thu, Nov 21, 2013 at 2:24 PM, Camille Teruel <camille.teruel@gmail.com> wrote:
On 21 nov. 2013, at 13:44, kilon alios <kilon.alios@gmail.com> wrote:
any links why newcomers like me should be impressed ? Whats the advantages ?
That's just cleaning. The old class builder was an incredibly complex piece of code that is now replaced with the Slot class builder. The later is based on slots and is much more understandable and thus much easier to maintain. It's been integrated some time ago thanks to Martin.
Slots are the work of Toon and Camillo and enables a lot of useful features: http://rmod.lille.inria.fr/archives/papers/Verw11a-OOSPLA11-FlexibleObjectLa... They are based on the reification of class layouts (variable,weak,fixed and co) and instance variables (slots). Slots are an abstraction added on top of low-level class "fields". It means that one will be able to create a customized slot class that define the logic to read and write a slot:
Object subclass: #MyClass slots: { x => MyFancySlot } category: 'Playground'
Then when a method read or writes x, the logic you defined in MyFancySlot is executed. All that still need to be absorbed by Opal so it's not available right now but it will (Pharo 4)!
On Thu, Nov 21, 2013 at 2:21 PM, Tudor Girba <tudor@tudorgirba.com> wrote: Triple impressive! This is another sample of an apparently tiny change that actually has deep impact on the future of our beloved environment.
Ladies and gentlemen, I know you are busy, but please take the time to acknowledge it :)
Doru
On Thu, Nov 21, 2013 at 12:58 PM, Martin Dias <tinchodias@gmail.com> wrote: wow, impressive!
On Thu, Nov 21, 2013 at 9:02 AM, Marcus Denker <marcus.denker@inria.fr> wrote: Hi,
Yesterday Camille did the change to finally remove the old class builder! (just a removal + a small change to NativeBoost to use the new class builder to create anonymous classes).
This means - 1000 Loc of completely un-understandable code removed. - we now 100% run on the new class builder from the Slot Project.
Next on the list (not all for Pharo3):
- remove PackageInfo - old Browser + CodeHolder hierarchy - PseudoClass&Co â> Ring - old AST+Compiler (this in Pharo4)
We already did (all in Pharo3): -> remove URI -> deprecated Url for ZnUrl -> removed HTTPSocket facade -> MIMEType retired for ZnMimeType -> old Debugger is removed -> Class categories are replaced by Protocols
I am quite sure that these cleanups will enable us to build a lot of very interesting things in the future.
Marcus
-- www.tudorgirba.com
"Every thing has its own flow"
-- www.tudorgirba.com
"Every thing has its own flow"
How does this affect serialization / materialization engines like Fuel? On Thu, Nov 21, 2013 at 7:24 AM, Camille Teruel <camille.teruel@gmail.com> wrote:
On 21 nov. 2013, at 13:44, kilon alios <kilon.alios@gmail.com> wrote:
any links why newcomers like me should be impressed ? Whats the advantages ?
That's just cleaning. The old class builder was an incredibly complex piece of code that is now replaced with the Slot class builder. The later is based on slots and is much more understandable and thus much easier to maintain. It's been integrated some time ago thanks to Martin.
Slots are the work of Toon and Camillo and enables a lot of useful features: http://rmod.lille.inria.fr/archives/papers/Verw11a-OOSPLA11-FlexibleObjectLa... They are based on the reification of class layouts (variable,weak,fixed and co) and instance variables (slots). Slots are an abstraction added on top of low-level class "fields". It means that one will be able to create a customized slot class that define the logic to read and write a slot:
Object subclass: #MyClass slots: { x => MyFancySlot } category: 'Playground'
Then when a method read or writes x, the logic you defined in MyFancySlot is executed. All that still need to be absorbed by Opal so it's not available right now but it will (Pharo 4)!
On Thu, Nov 21, 2013 at 2:21 PM, Tudor Girba <tudor@tudorgirba.com> wrote:
Triple impressive! This is another sample of an apparently tiny change that actually has deep impact on the future of our beloved environment.
Ladies and gentlemen, I know you are busy, but please take the time to acknowledge it :)
Doru
On Thu, Nov 21, 2013 at 12:58 PM, Martin Dias <tinchodias@gmail.com> wrote:
wow, impressive!
On Thu, Nov 21, 2013 at 9:02 AM, Marcus Denker <marcus.denker@inria.fr> wrote:
Hi,
Yesterday Camille did the change to finally remove the old class builder! (just a removal + a small change to NativeBoost to use the new class builder to create anonymous classes).
This means - 1000 Loc of completely un-understandable code removed. - we now 100% run on the new class builder from the Slot Project.
Next on the list (not all for Pharo3):
- remove PackageInfo - old Browser + CodeHolder hierarchy - PseudoClass&Co â> Ring - old AST+Compiler (this in Pharo4)
We already did (all in Pharo3): -> remove URI -> deprecated Url for ZnUrl -> removed HTTPSocket facade -> MIMEType retired for ZnMimeType -> old Debugger is removed -> Class categories are replaced by Protocols
I am quite sure that these cleanups will enable us to build a lot of very interesting things in the future.
Marcus
-- www.tudorgirba.com
"Every thing has its own flow"
On 22 nov. 2013, at 21:03, Chris Muller <asqueaker@gmail.com> wrote:
How does this affect serialization / materialization engines like Fuel?
That's a good question Chris! My impression is that serialization / materialization should not trigger custom read / write slot logic. Fuel should serialize objects as they are in memory not how they appear through the read/write slot methods. For example, imagine you have a HistorySlot that stores the history of the different writes. The actual associated field would be an ordered collection, the write method would add a new value to this collection and the read method would return the last element of the list. So an object whose class use such a slot would point to an ordered collection but through the slot logic it would appear to point to the last element of that collection. Then when you want to serialize an instance of a class that use such a slot, I think you want to serialize the whole collection not only the last value. Because else the materialization would create an object whose state is inconsistant with the slot logic (you could have DNUs like "SomeClass does not understand: #addLast:" on writes and "SomeClass does not understand: #last" on reads). So, IMO Fuel should work like it works today, without taking slots into account. But maybe they are some weird cases where you want to trigger the slot logic, I don't know.
On Thu, Nov 21, 2013 at 7:24 AM, Camille Teruel <camille.teruel@gmail.com> wrote:
On 21 nov. 2013, at 13:44, kilon alios <kilon.alios@gmail.com> wrote:
any links why newcomers like me should be impressed ? Whats the advantages ?
That's just cleaning. The old class builder was an incredibly complex piece of code that is now replaced with the Slot class builder. The later is based on slots and is much more understandable and thus much easier to maintain. It's been integrated some time ago thanks to Martin.
Slots are the work of Toon and Camillo and enables a lot of useful features: http://rmod.lille.inria.fr/archives/papers/Verw11a-OOSPLA11-FlexibleObjectLa... They are based on the reification of class layouts (variable,weak,fixed and co) and instance variables (slots). Slots are an abstraction added on top of low-level class "fields". It means that one will be able to create a customized slot class that define the logic to read and write a slot:
Object subclass: #MyClass slots: { x => MyFancySlot } category: 'Playground'
Then when a method read or writes x, the logic you defined in MyFancySlot is executed. All that still need to be absorbed by Opal so it's not available right now but it will (Pharo 4)!
On Thu, Nov 21, 2013 at 2:21 PM, Tudor Girba <tudor@tudorgirba.com> wrote:
Triple impressive! This is another sample of an apparently tiny change that actually has deep impact on the future of our beloved environment.
Ladies and gentlemen, I know you are busy, but please take the time to acknowledge it :)
Doru
On Thu, Nov 21, 2013 at 12:58 PM, Martin Dias <tinchodias@gmail.com> wrote:
wow, impressive!
On Thu, Nov 21, 2013 at 9:02 AM, Marcus Denker <marcus.denker@inria.fr> wrote:
Hi,
Yesterday Camille did the change to finally remove the old class builder! (just a removal + a small change to NativeBoost to use the new class builder to create anonymous classes).
This means - 1000 Loc of completely un-understandable code removed. - we now 100% run on the new class builder from the Slot Project.
Next on the list (not all for Pharo3):
- remove PackageInfo - old Browser + CodeHolder hierarchy - PseudoClass&Co â> Ring - old AST+Compiler (this in Pharo4)
We already did (all in Pharo3): -> remove URI -> deprecated Url for ZnUrl -> removed HTTPSocket facade -> MIMEType retired for ZnMimeType -> old Debugger is removed -> Class categories are replaced by Protocols
I am quite sure that these cleanups will enable us to build a lot of very interesting things in the future.
Marcus
-- www.tudorgirba.com
"Every thing has its own flow"
How does this affect serialization / materialization engines like Fuel?
Not now We will have to work to make the compiler smarter and define special Slot class.
On 21 nov. 2013, at 13:44, kilon alios <kilon.alios@gmail.com> wrote:
any links why newcomers like me should be impressed ? Whats the advantages ?
That's just cleaning. The old class builder was an incredibly complex piece of code that is now replaced with the Slot class builder. The later is based on slots and is much more understandable and thus much easier to maintain. It's been integrated some time ago thanks to Martin.
Slots are the work of Toon and Camillo and enables a lot of useful features: http://rmod.lille.inria.fr/archives/papers/Verw11a-OOSPLA11-FlexibleObjectLa... They are based on the reification of class layouts (variable,weak,fixed and co) and instance variables (slots). Slots are an abstraction added on top of low-level class "fields". It means that one will be able to create a customized slot class that define the logic to read and write a slot:
Object subclass: #MyClass slots: { x => MyFancySlot } category: 'Playground'
Then when a method read or writes x, the logic you defined in MyFancySlot is executed. All that still need to be absorbed by Opal so it's not available right now but it will (Pharo 4)!
On Thu, Nov 21, 2013 at 2:21 PM, Tudor Girba <tudor@tudorgirba.com> wrote:
Triple impressive! This is another sample of an apparently tiny change that actually has deep impact on the future of our beloved environment.
Ladies and gentlemen, I know you are busy, but please take the time to acknowledge it :)
Doru
On Thu, Nov 21, 2013 at 12:58 PM, Martin Dias <tinchodias@gmail.com> wrote:
wow, impressive!
On Thu, Nov 21, 2013 at 9:02 AM, Marcus Denker <marcus.denker@inria.fr> wrote:
Hi,
Yesterday Camille did the change to finally remove the old class builder! (just a removal + a small change to NativeBoost to use the new class builder to create anonymous classes).
This means - 1000 Loc of completely un-understandable code removed. - we now 100% run on the new class builder from the Slot Project.
Next on the list (not all for Pharo3):
- remove PackageInfo - old Browser + CodeHolder hierarchy - PseudoClass&Co â> Ring - old AST+Compiler (this in Pharo4)
We already did (all in Pharo3): -> remove URI -> deprecated Url for ZnUrl -> removed HTTPSocket facade -> MIMEType retired for ZnMimeType -> old Debugger is removed -> Class categories are replaced by Protocols
I am quite sure that these cleanups will enable us to build a lot of very interesting things in the future.
Marcus
-- www.tudorgirba.com
"Every thing has its own flow"
Mmm... if slots support annotations, maybe the user can tag an instance variable with a "ignore" tag. At this moment, the user can override #fuelIgnoredInstanceVariableNames to do that, answering a list of variable names. MartÃn On Sat, Nov 23, 2013 at 5:46 PM, Stéphane Ducasse <stephane.ducasse@inria.fr
wrote:
How does this affect serialization / materialization engines like Fuel?
Not now We will have to work to make the compiler smarter and define special Slot class.
On 21 nov. 2013, at 13:44, kilon alios <kilon.alios@gmail.com> wrote:
any links why newcomers like me should be impressed ? Whats the advantages ?
That's just cleaning. The old class builder was an incredibly complex piece of code that is now replaced with the Slot class builder. The later is based on slots and is much more understandable and thus much easier to maintain. It's been integrated some time ago thanks to Martin.
Slots are the work of Toon and Camillo and enables a lot of useful features:
http://rmod.lille.inria.fr/archives/papers/Verw11a-OOSPLA11-FlexibleObjectLa...
They are based on the reification of class layouts (variable,weak,fixed and co) and instance variables (slots). Slots are an abstraction added on top of low-level class "fields". It means that one will be able to create a customized slot class that define the logic to read and write a slot:
Object subclass: #MyClass slots: { x => MyFancySlot } category: 'Playground'
Then when a method read or writes x, the logic you defined in MyFancySlot is executed. All that still need to be absorbed by Opal so it's not available right now but it will (Pharo 4)!
On Thu, Nov 21, 2013 at 2:21 PM, Tudor Girba <tudor@tudorgirba.com> wrote:
Triple impressive! This is another sample of an apparently tiny change that actually has deep impact on the future of our beloved environment.
Ladies and gentlemen, I know you are busy, but please take the time to acknowledge it :)
Doru
On Thu, Nov 21, 2013 at 12:58 PM, Martin Dias <tinchodias@gmail.com> wrote:
wow, impressive!
On Thu, Nov 21, 2013 at 9:02 AM, Marcus Denker <
marcus.denker@inria.fr>
wrote:
Hi,
Yesterday Camille did the change to finally remove the old class builder! (just a removal + a small change to NativeBoost to use the new class builder to create anonymous classes).
This means - 1000 Loc of completely un-understandable code removed. - we now 100% run on the new class builder from the Slot Project.
Next on the list (not all for Pharo3):
- remove PackageInfo - old Browser + CodeHolder hierarchy - PseudoClass&Co â> Ring - old AST+Compiler (this in Pharo4)
We already did (all in Pharo3): -> remove URI -> deprecated Url for ZnUrl -> removed HTTPSocket facade -> MIMEType retired for ZnMimeType -> old Debugger is removed -> Class categories are replaced by Protocols
I am quite sure that these cleanups will enable us to build a lot of very interesting things in the future.
Marcus
-- www.tudorgirba.com
"Every thing has its own flow"
With the object's format reified in Layouts, we could rewrite a method like this by a double-dispatch: Object >> fuelAccept: aGeneralMapper "Be careful because the order is important. For example, weak are also variable, but we need that weak objects send #visitWeakObject: and not #visitVariableObject: " self class isFixed ifTrue: [ ^ aGeneralMapper visitFixedObject: self ]. self class isWeak ifTrue: [ ^ aGeneralMapper visitWeakObject: self ]. self class isPointers ifTrue: [ ^ aGeneralMapper visitVariableObject: self ]. self class isBytes ifTrue: [ ^ aGeneralMapper visitBytesObject: self ]. self class isWords ifTrue: [ ^ aGeneralMapper visitWordsObject: self ]. self error: 'Something is wrong!' MartÃn On Mon, Nov 25, 2013 at 4:04 PM, Martin Dias <tinchodias@gmail.com> wrote:
Mmm... if slots support annotations, maybe the user can tag an instance variable with a "ignore" tag.
At this moment, the user can override #fuelIgnoredInstanceVariableNames to do that, answering a list of variable names.
MartÃn
On Sat, Nov 23, 2013 at 5:46 PM, Stéphane Ducasse < stephane.ducasse@inria.fr> wrote:
How does this affect serialization / materialization engines like Fuel?
Not now We will have to work to make the compiler smarter and define special Slot class.
On 21 nov. 2013, at 13:44, kilon alios <kilon.alios@gmail.com> wrote:
any links why newcomers like me should be impressed ? Whats the advantages ?
That's just cleaning. The old class builder was an incredibly complex piece of code that is now replaced with the Slot class builder. The later is based on slots and is much more understandable and thus much easier to maintain. It's been integrated some time ago thanks to Martin.
Slots are the work of Toon and Camillo and enables a lot of useful features:
http://rmod.lille.inria.fr/archives/papers/Verw11a-OOSPLA11-FlexibleObjectLa...
They are based on the reification of class layouts (variable,weak,fixed and co) and instance variables (slots). Slots are an abstraction added on top of low-level class "fields". It means that one will be able to create a customized slot class that define the logic to read and write a slot:
Object subclass: #MyClass slots: { x => MyFancySlot } category: 'Playground'
Then when a method read or writes x, the logic you defined in MyFancySlot is executed. All that still need to be absorbed by Opal so it's not available right now but it will (Pharo 4)!
On Thu, Nov 21, 2013 at 2:21 PM, Tudor Girba <tudor@tudorgirba.com> wrote:
Triple impressive! This is another sample of an apparently tiny change that actually has deep impact on the future of our beloved
environment.
Ladies and gentlemen, I know you are busy, but please take the time to acknowledge it :)
Doru
On Thu, Nov 21, 2013 at 12:58 PM, Martin Dias <tinchodias@gmail.com> wrote:
wow, impressive!
On Thu, Nov 21, 2013 at 9:02 AM, Marcus Denker <
marcus.denker@inria.fr>
wrote:
Hi,
Yesterday Camille did the change to finally remove the old class builder! (just a removal + a small change to NativeBoost to use the new class builder to create anonymous classes).
This means - 1000 Loc of completely un-understandable code removed. - we now 100% run on the new class builder from the Slot Project.
Next on the list (not all for Pharo3):
- remove PackageInfo - old Browser + CodeHolder hierarchy - PseudoClass&Co â> Ring - old AST+Compiler (this in Pharo4)
We already did (all in Pharo3): -> remove URI -> deprecated Url for ZnUrl -> removed HTTPSocket facade -> MIMEType retired for ZnMimeType -> old Debugger is removed -> Class categories are replaced by Protocols
I am quite sure that these cleanups will enable us to build a lot of very interesting things in the future.
Marcus
-- www.tudorgirba.com
"Every thing has its own flow"
On Nov 21, 2013, at 2:24 PM, Camille Teruel <camille.teruel@gmail.com> wrote:
On 21 nov. 2013, at 13:44, kilon alios <kilon.alios@gmail.com> wrote:
any links why newcomers like me should be impressed ? Whats the advantages ?
That's just cleaning.
No this is more than that. Classbuilder was an horrible beast.
The old class builder was an incredibly complex piece of code that is now replaced with the Slot class builder. The later is based on slots and is much more understandable and thus much easier to maintain. It's been integrated some time ago thanks to Martin.
Slots are the work of Toon and Camillo and enables a lot of useful features: http://rmod.lille.inria.fr/archives/papers/Verw11a-OOSPLA11-FlexibleObjectLa... They are based on the reification of class layouts (variable,weak,fixed and co) and instance variables (slots). Slots are an abstraction added on top of low-level class "fields". It means that one will be able to create a customized slot class that define the logic to read and write a slot:
Object subclass: #MyClass slots: { x => MyFancySlot } category: 'Playground'
Then when a method read or writes x, the logic you defined in MyFancySlot is executed. All that still need to be absorbed by Opal so it's not available right now but it will (Pharo 4)!
On Thu, Nov 21, 2013 at 2:21 PM, Tudor Girba <tudor@tudorgirba.com> wrote: Triple impressive! This is another sample of an apparently tiny change that actually has deep impact on the future of our beloved environment.
Ladies and gentlemen, I know you are busy, but please take the time to acknowledge it :)
Doru
On Thu, Nov 21, 2013 at 12:58 PM, Martin Dias <tinchodias@gmail.com> wrote: wow, impressive!
On Thu, Nov 21, 2013 at 9:02 AM, Marcus Denker <marcus.denker@inria.fr> wrote: Hi,
Yesterday Camille did the change to finally remove the old class builder! (just a removal + a small change to NativeBoost to use the new class builder to create anonymous classes).
This means - 1000 Loc of completely un-understandable code removed. - we now 100% run on the new class builder from the Slot Project.
Next on the list (not all for Pharo3):
- remove PackageInfo - old Browser + CodeHolder hierarchy - PseudoClass&Co â> Ring - old AST+Compiler (this in Pharo4)
We already did (all in Pharo3): -> remove URI -> deprecated Url for ZnUrl -> removed HTTPSocket facade -> MIMEType retired for ZnMimeType -> old Debugger is removed -> Class categories are replaced by Protocols
I am quite sure that these cleanups will enable us to build a lot of very interesting things in the future.
Marcus
-- www.tudorgirba.com
"Every thing has its own flow"
kilon alios wrote
any links why newcomers like me should be impressed ? Whats the advantages?
Great question! As Camille mentioned, the email is more about cleaning. As a new user, this will likely effect you in two ways. The new clean replacement code: 1) will empower members of our community to write killer IDE enhancements and libraries that you can use 2) will allow you to express yourself in code more effectively. I remember when I first found Smalltalk. I was smitten by the promise of turtles-all-the-way-down, all parts of the system available for exploration and modification. This was quickly followed by the reality of (sometimes) impossible (for me anyway) to understand code (cough... Morphic, FileDirectory). On several shoot-the-moon IDE ideas, I became frustrated and quit. Now we have FileSystem, which is a joy to work with, and rarely gets in my way. Multiply this by the number of items above, and all the others over the releases of Pharo, and... you get the picture... HTH ----- Cheers, Sean -- View this message in context: http://forum.world.st/Old-ClassBuilder-remove-tp4723906p4723980.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Tudor Girba-2 wrote
Triple impressive! This is another sample of an apparently tiny change that actually has deep impact on the future of our beloved environment.
Yes!!!! ----- Cheers, Sean -- View this message in context: http://forum.world.st/Old-ClassBuilder-remove-tp4723906p4723979.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
I don't fully see what are the immediate benefits. But as usually happen when you replace something old, limited and "not so well designed" by something better designed from the ground up I guess it will open Pharo to features not yet thought of. Does the new debugger have something "better" than the previous one? Regards! Esteban A. Maringolo 2013/11/21 Tudor Girba <tudor@tudorgirba.com>:
Triple impressive! This is another sample of an apparently tiny change that actually has deep impact on the future of our beloved environment.
Ladies and gentlemen, I know you are busy, but please take the time to acknowledge it :)
Doru
On Thu, Nov 21, 2013 at 12:58 PM, Martin Dias <tinchodias@gmail.com> wrote:
wow, impressive!
On Thu, Nov 21, 2013 at 9:02 AM, Marcus Denker <marcus.denker@inria.fr> wrote:
Hi,
Yesterday Camille did the change to finally remove the old class builder! (just a removal + a small change to NativeBoost to use the new class builder to create anonymous classes).
This means - 1000 Loc of completely un-understandable code removed. - we now 100% run on the new class builder from the Slot Project.
Next on the list (not all for Pharo3):
- remove PackageInfo - old Browser + CodeHolder hierarchy - PseudoClass&Co â> Ring - old AST+Compiler (this in Pharo4)
We already did (all in Pharo3): -> remove URI -> deprecated Url for ZnUrl -> removed HTTPSocket facade -> MIMEType retired for ZnMimeType -> old Debugger is removed -> Class categories are replaced by Protocols
I am quite sure that these cleanups will enable us to build a lot of very interesting things in the future.
Marcus
-- www.tudorgirba.com
"Every thing has its own flow"
yeah me too Esteban, I checked the link to the pdf but is written in a language its very difficult to understand. Also Sean points tell me nothing about this feature, they look too generic. Oh well maybe its for the people that want to deeply hack the language and system which is not my area of expertise or interest. In any case any positive contribution to Pharo whether interests me or not is ALWAYS welcomed, so thank you :) On Thu, Nov 21, 2013 at 4:21 PM, Esteban A. Maringolo <emaringolo@gmail.com>wrote:
I don't fully see what are the immediate benefits.
But as usually happen when you replace something old, limited and "not so well designed" by something better designed from the ground up I guess it will open Pharo to features not yet thought of.
Does the new debugger have something "better" than the previous one?
Regards! Esteban A. Maringolo
2013/11/21 Tudor Girba <tudor@tudorgirba.com>:
Triple impressive! This is another sample of an apparently tiny change that actually has deep impact on the future of our beloved environment.
Ladies and gentlemen, I know you are busy, but please take the time to acknowledge it :)
Doru
On Thu, Nov 21, 2013 at 12:58 PM, Martin Dias <tinchodias@gmail.com> wrote:
wow, impressive!
On Thu, Nov 21, 2013 at 9:02 AM, Marcus Denker <marcus.denker@inria.fr> wrote:
Hi,
Yesterday Camille did the change to finally remove the old class
builder!
(just a removal + a small change to NativeBoost to use the new class builder to create anonymous classes).
This means - 1000 Loc of completely un-understandable code removed. - we now 100% run on the new class builder from the Slot Project.
Next on the list (not all for Pharo3):
- remove PackageInfo - old Browser + CodeHolder hierarchy - PseudoClass&Co â> Ring - old AST+Compiler (this in Pharo4)
We already did (all in Pharo3): -> remove URI -> deprecated Url for ZnUrl -> removed HTTPSocket facade -> MIMEType retired for ZnMimeType -> old Debugger is removed -> Class categories are replaced by Protocols
I am quite sure that these cleanups will enable us to build a lot of very interesting things in the future.
Marcus
-- www.tudorgirba.com
"Every thing has its own flow"
On Nov 21, 2013, at 3:21 PM, Esteban A. Maringolo <emaringolo@gmail.com> wrote:
I don't fully see what are the immediate benefits.
But as usually happen when you replace something old, limited and "not so well designed" by something better designed from the ground up I guess it will open Pharo to features not yet thought of.
Does the new debugger have something "better" than the previous one?
Having a real a model and a UI separated. We can script the debugger now and create different UIs. Just that should make you happy. browse the code of the Debugger in Pharo 20 or 1.4 and try to find where is the UI defined :)
Regards! Esteban A. Maringolo
2013/11/21 Tudor Girba <tudor@tudorgirba.com>:
Triple impressive! This is another sample of an apparently tiny change that actually has deep impact on the future of our beloved environment.
Ladies and gentlemen, I know you are busy, but please take the time to acknowledge it :)
Doru
On Thu, Nov 21, 2013 at 12:58 PM, Martin Dias <tinchodias@gmail.com> wrote:
wow, impressive!
On Thu, Nov 21, 2013 at 9:02 AM, Marcus Denker <marcus.denker@inria.fr> wrote:
Hi,
Yesterday Camille did the change to finally remove the old class builder! (just a removal + a small change to NativeBoost to use the new class builder to create anonymous classes).
This means - 1000 Loc of completely un-understandable code removed. - we now 100% run on the new class builder from the Slot Project.
Next on the list (not all for Pharo3):
- remove PackageInfo - old Browser + CodeHolder hierarchy - PseudoClass&Co â> Ring - old AST+Compiler (this in Pharo4)
We already did (all in Pharo3): -> remove URI -> deprecated Url for ZnUrl -> removed HTTPSocket facade -> MIMEType retired for ZnMimeType -> old Debugger is removed -> Class categories are replaced by Protocols
I am quite sure that these cleanups will enable us to build a lot of very interesting things in the future.
Marcus
-- www.tudorgirba.com
"Every thing has its own flow"
On 21 Nov 2013, at 13:21, Tudor Girba <tudor@tudorgirba.com> wrote:
Triple impressive! This is another sample of an apparently tiny change that actually has deep impact on the future of our beloved environment.
Ladies and gentlemen, I know you are busy, but please take the time to acknowledge it :)
Doru
+10 Also, all these changes in different areas reinforce each other. That is Pharo.
On Thu, Nov 21, 2013 at 12:58 PM, Martin Dias <tinchodias@gmail.com> wrote: wow, impressive!
On Thu, Nov 21, 2013 at 9:02 AM, Marcus Denker <marcus.denker@inria.fr> wrote: Hi,
Yesterday Camille did the change to finally remove the old class builder! (just a removal + a small change to NativeBoost to use the new class builder to create anonymous classes).
This means - 1000 Loc of completely un-understandable code removed. - we now 100% run on the new class builder from the Slot Project.
Next on the list (not all for Pharo3):
- remove PackageInfo - old Browser + CodeHolder hierarchy - PseudoClass&Co â> Ring - old AST+Compiler (this in Pharo4)
We already did (all in Pharo3): -> remove URI -> deprecated Url for ZnUrl -> removed HTTPSocket facade -> MIMEType retired for ZnMimeType -> old Debugger is removed -> Class categories are replaced by Protocols
I am quite sure that these cleanups will enable us to build a lot of very interesting things in the future.
Marcus
-- www.tudorgirba.com
"Every thing has its own flow"
On Nov 21, 2013, at 9:02 AM, Marcus Denker <marcus.denker@inria.fr> wrote:
Hi,
Yesterday Camille did the change to finally remove the old class builder! (just a removal + a small change to NativeBoost to use the new class builder to create anonymous classes).
This means - 1000 Loc of completely un-understandable code removed.
oh yes!
- we now 100% run on the new class builder from the Slot Project.
Excellent. There is so many things that I would like to do (think about bootstrap and mini kernel).
Next on the list (not all for Pharo3):
- remove PackageInfo - old Browser + CodeHolder hierarchy - PseudoClass&Co â> Ring - old AST+Compiler (this in Pharo4)
We already did (all in Pharo3): -> remove URI -> deprecated Url for ZnUrl -> removed HTTPSocket facade -> MIMEType retired for ZnMimeType -> old Debugger is removed -> Class categories are replaced by Protocols
I am quite sure that these cleanups will enable us to build a lot of very interesting things in the future.
yes :)
participants (13)
-
Camille Teruel -
Chris Muller -
Esteban A. Maringolo -
kilon alios -
Luc Fabresse -
Marcus Denker -
Martin Dias -
Norbert Hartl -
phil＠highoctane.be -
Sean P. DeNigris -
Stéphane Ducasse -
Sven Van Caekenberghe -
Tudor Girba