Old ClassBuilder remove!
Locked
12
12
Re: Old ClassBuilder remove!
 
|
Nicolas wrote:
>It has to be more simple than that… Probably. I don’t do this often enough. >Why not searching for allReferences to true and false, and gather the class of referents? How is that going to give me the values of the instVars? >This would also remove the limitation of first 10 instances… Taking a look at all instances just takes a bit longer... I’m open to suggestions. Stephan |
|
|
In reply to this post by camille teruel
How does this affect serialization / materialization engines like Fuel?
On Thu, Nov 21, 2013 at 7:24 AM, Camille Teruel <[hidden email]> wrote: > > On 21 nov. 2013, at 13:44, kilon alios <[hidden email]> 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-FlexibleObjectLayouts.pdf > 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 <[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 >> >> >> >> >> 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" > > > |
|
|
In reply to this post by Tudor Girba-2
> 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? |
|
|
In reply to this post by Stephan Eggermont-3
(true pointersTo collect: #class as: Set) intersection: (false pointersTo collect: #class as: Set) et voila2013/11/22 Stephan Eggermont <[hidden email]> Nicolas wrote: |
|
|
OK, got it, nothing tells that they come from same slot... At least you have a pre-filter. 2013/11/22 Nicolas Cellier <[hidden email]>
|
|
|
In reply to this post by Chris Muller-3
On 22 nov. 2013, at 21:03, Chris Muller <[hidden email]> 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 > <[hidden email]> wrote: >> >> On 21 nov. 2013, at 13:44, kilon alios <[hidden email]> 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-FlexibleObjectLayouts.pdf >> 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 <[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 >>> >>> >>> >>> >>> 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
On 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. 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 :) |
Re: Old ClassBuilder remove!
|
|
In reply to this post by camille teruel
On Nov 21, 2013, at 2:24 PM, Camille Teruel <[hidden email]> wrote:
|
Re: Old ClassBuilder remove!
|
|
In reply to this post by Tudor Girba-2
+ 1000
I want relationship using Slot :) Stef On Nov 21, 2013, at 2:45 PM, Tudor Girba <[hidden email]> wrote:
|
Re: Old ClassBuilder remove!
|
|
In reply to this post by Tudor Girba-2
On Nov 21, 2013, at 2:49 PM, Tudor Girba <[hidden email]> 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 |
|
|
In reply to this post by Chris Muller-3
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 |
Re: Old ClassBuilder remove!
|
|
In reply to this post by Esteban A. Maringolo
On Nov 21, 2013, at 3:21 PM, Esteban A. Maringolo <[hidden email]> 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 <[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" > |
Re: Old ClassBuilder remove!
|
|
In reply to this post by Stephan Eggermont-3
sweet queries :)
>> 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. > > |
Re: Old ClassBuilder remove!
|
|
In reply to this post by Chris Muller-3
> 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 <[hidden email]> 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-FlexibleObjectLayouts.pdf >> 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 <[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 >>> >>> >>> >>> >>> 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" >> >> >> > |
|
|
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 <[hidden email]> wrote:
|
|
|
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 <[hidden email]> wrote:
|
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |