On 22 nov. 2013, at 21:03, Chris Muller <asquea...@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.ter...@gmail.com> wrote: >> >> On 21 nov. 2013, at 13:44, kilon alios <kilon.al...@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-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 <tu...@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 <tinchod...@gmail.com> >>> wrote: >>>> >>>> wow, impressive! >>>> >>>> >>>> On Thu, Nov 21, 2013 at 9:02 AM, Marcus Denker <marcus.den...@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" >> >> >> >
