> On 28 May 2017, at 10:39, Ben Coman <b...@openinworld.com> wrote: > > On Sat, May 27, 2017 at 5:41 PM, K K Subbu <kksubbu...@gmail.com> wrote: >> On Saturday 27 May 2017 01:41 PM, Ben Coman wrote: >>> >>> A question arose in Discord regarding #basicNew, to which I felt like >>> the proper answer should be >>> that #basicNew is used only** from the class-side when making custom >>> initializers. >>> (**excepting special meta-handling like by Behaviour) >> >> >> AFAIK, #basicNew is a low-level essential method which should *never* be >> overridden by application methods, while #new offers a stable facade over >> #basicNew for applications. >> >> Essentially, #basic* methods are calls to primitives in VM which reify basic >> objects of the object model like float, symbols etc. They are coupled >> closely with interpreter and object memory structures and functions. >> Application classes do not concern themselves with size and layout of such >> objects and use the facade methods like #new. >> >> It is like the difference between a system call and runtime C library >> function. A C function like malloc maintains a stable interface to the app >> while its makes different system calls on different OS implementations. >> >> HTH .. Subbu >> > > Thanks Subbu. That is a useful insight for me, but is about the > implementation. > My query was more about senders of basicNew, so is still open if you > have an opinion there, or anyone else. > cheers -ben
Normally #basicNew is an implementation detail. It is however often used to prevent #initialize from happening (#new being #basicNew followed by #initialize). If that is the case, then it is probably a design error. Sven