Old ClassBuilder remove!
Locked
12
12
 
|
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 <[hidden email]> wrote: Hi, |
|
|
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 <[hidden email]> wrote:
"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 <[hidden email]> wrote:
|
|
|
In reply to this post by Tudor Girba-2
Am 21.11.2013 um 13:21 schrieb Tudor Girba <[hidden email]>: Ladies and gentlemen, I know you are busy, but please take the time to acknowledge it :) full ack Norbert
|
|
|
In reply to this post by kilon.alios
On 21 nov. 2013, at 13:44, kilon alios <[hidden email]> wrote:
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: 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)!
|
|
|
facking awesome !
On Thursday, November 21, 2013, Camille Teruel wrote:
-- --- Philippe Back Dramatic Performance Improvements Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027
Blog: http://philippeback.be | Twitter: @philippeback
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
|
|
|
In reply to this post by camille teruel
yes thanks a lot! I like cleaning. #Luc 2013/11/21 Camille Teruel <[hidden email]>
|
|
|
In reply to this post by camille teruel
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 <[hidden email]> wrote:
"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 <[hidden email]> wrote:
"Every thing has its own flow"
|
Re: Old ClassBuilder remove!
|
Administrator
|
In reply to this post by Tudor Girba-2
Yes!!!!
Cheers,
Sean |
|
|
In reply to this post by Tudor Girba-2
On 21 nov. 2013, at 14:45, Tudor Girba <[hidden email]> wrote:
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 :)
|
Re: Old ClassBuilder remove!
|
Administrator
|
In reply to this post by kilon.alios
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 |
Re: Old ClassBuilder remove!
|
|
In reply to this post by Tudor Girba-2
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 <[hidden email]>: > 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 <[hidden email]> wrote: >> >> wow, impressive! >> >> >> On Thu, Nov 21, 2013 at 9:02 AM, Marcus Denker <[hidden email]> >> 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 <[hidden email]> wrote: I don't fully see what are the immediate benefits. |
Re: Old ClassBuilder remove!
|
|
In reply to this post by Tudor Girba-2
On 21 Nov 2013, at 13:21, Tudor Girba <[hidden email]> 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 <[hidden email]> wrote: > wow, impressive! > > > On Thu, Nov 21, 2013 at 9:02 AM, Marcus Denker <[hidden email]> 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" |
Re: Old ClassBuilder remove!
|
|
In reply to this post by Marcus Denker-4
Nice!
kilon wrote: >any links why newcomers like me should be impressed ? Whats the advantages ? Then we can now have more compact versions of FreeTypeSettings LabelMorph MorphTreeNodeMorph MorphTreeListManager ThemeSettings MultistateButtonMorph PharoUserPermissions SimpleHierarchicalListMorph Nautilus class SpecTreeColumn PluggableIconListMorph MorphTreeMorph Workspace CompositionScanner Paragraph MethodOveridesAction HandMorph TextComposer ScrollBar NECContext MultiByteFileStream NewValueHolder DynamicClassGroup SearchMorph NautilusHistoryEntry PluggableTextFieldMorph PluggableListMorph TableLayoutProperties DynamicGroup DropListMorph GradientFillStyle PackageTreeNautilus PluggableTextMorphWithLimits NECUntypedModel BalloonEngine MetacelloPharo30Platform SystemWindow NautilusWindow NECPreferences class EditorFindReplaceDialogWindow GoBackStringMorph NautilusHistoryEntryWithSourceCode MCCacheRepository PluggableButtonMorph AlphaImageMorph PluggableTextMorph RxMatcher MorphExtension TextMorphForFieldView MorphTreeColumn FindReplaceService CheckboxMorph TextMorphForEditView IndentingListItemMorph ControlButtonMorph CheckboxButtonMorph with multiple booleans mapped to one instVar |set| set := IdentitySet new. Object allSubclasses do: [ :aClass | |varSize coll nr candidate | candidate := false. varSize := aClass instSize. coll := aClass allInstances. nr := 10 min: coll size. (coll first: nr) do: [ :anInstance | |value nrBoolean| nrBoolean := 0. 1 to: varSize do: [ :varIndex | value := anInstance instVarAt: varIndex. value class = True ifTrue: [ nrBoolean := nrBoolean + 1 ]. value class = False ifTrue: [ nrBoolean := nrBoolean + 1 ]]. nrBoolean >1 ifTrue: [ candidate := true ] ]. candidate ifTrue: [ set add: aClass ]]. set. |
|
|
On 2013-11-22, at 11:56, Stephan Eggermont <[hidden email]> wrote: > Nice! > > kilon wrote: >> any links why newcomers like me should be impressed ? Whats the advantages ? > > Then we can now have more compact versions of > > FreeTypeSettings LabelMorph MorphTreeNodeMorph MorphTreeListManager ThemeSettings MultistateButtonMorph PharoUserPermissions SimpleHierarchicalListMorph Nautilus class SpecTreeColumn PluggableIconListMorph MorphTreeMorph Workspace CompositionScanner Paragraph MethodOveridesAction HandMorph TextComposer ScrollBar NECContext MultiByteFileStream NewValueHolder DynamicClassGroup SearchMorph NautilusHistoryEntry PluggableTextFieldMorph PluggableListMorph TableLayoutProperties DynamicGroup DropListMorph GradientFillStyle PackageTreeNautilus PluggableTextMorphWithLimits NECUntypedModel BalloonEngine MetacelloPharo30Platform SystemWindow NautilusWindow NECPreferences class EditorFindReplaceDialogWindow GoBackStringMorph NautilusHistoryEntryWithSourceCode MCCacheRepository PluggableButtonMorph AlphaImageMorph PluggableTextMorph RxMatcher MorphExtension TextMorphForFieldView MorphTreeColumn FindReplaceService CheckboxMorph TextMorphForEditView IndentingListItemMorph ControlButtonMorph CheckboxButtonMorph > > with multiple booleans mapped to one instVar > > > |set| > set := IdentitySet new. > Object allSubclasses do: [ :aClass | > |varSize coll nr candidate | > candidate := false. > varSize := aClass instSize. > coll := aClass allInstances. > nr := 10 min: coll size. > (coll first: nr) do: [ :anInstance | > |value nrBoolean| > nrBoolean := 0. > 1 to: varSize do: [ :varIndex | > value := anInstance instVarAt: varIndex. > value class = True ifTrue: [ nrBoolean := nrBoolean + 1 ]. > value class = False ifTrue: [ nrBoolean := nrBoolean + 1 ]]. > nrBoolean >1 ifTrue: [ candidate := true ] ]. > candidate ifTrue: [ set add: aClass ]]. > set. maybe you should make gists [1] out of them :) [1] https://gist.github.com/ |
signature.asc (457 bytes)
Re: Old ClassBuilder remove!
|
|
In reply to this post by Marcus Denker-4
Camillo wrote:
>I love these scripts :P.. >maybe you should make gists [1] out of them :) Good idea https://gist.github.com/StephanEggermont/7598946 |
|
|
It has to be more simple than that... This would also remove the limitation of first 10 instances...Why not searching for allReferences to true and false, and gather the class of referents? 2013/11/22 Stephan Eggermont <[hidden email]>
|
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |