On Sunday 07 May 2017 18:48:13 Marcos Douglas B. Santos wrote: > On Sun, May 7, 2017 at 1:14 PM, Martin Schreiber <mse00...@gmail.com> wrote: > >> Classes should not exists in object-oriented programming. This is a > >> mistake. Only objects should exists. > > > > In MSElang "class" = "^object" on heap. So you mean there should be no > > object heap pointers but stack allocated objects only? I probably > > misunderstood. > > No. I'm talking just about design concepts. > I want to work with objects. If they are created in heap or not, I don't > care. But... forget that. This concept will change all in MSElang. > > About your design, if "class" = "^object", why do not keep only one? > > Using your syntax, I propose this: > > 1. TObj = object [static] << this is like record > > 2. TObj = object [dynamic] << this is like class > Currently it can be defined in "var" section " var obj1: TObj; //on stack obj2: ^TObj; //on heap begin //obj1 does not need to be created obj2:= tobj.create(); obj2.destroy(); " or in "type" section " type TObj = object end; PObj = ^TObj; var obj1 = TObj; obj2 = PObj; begin //obj1 does not need to be created obj2:= tobj.create(); obj2.destroy(); " One does not need to use "class", it can be removed. I thought that people comming from Free Pascal will like it. ;-)
> But a clean syntax that is much BETTER is only: > > TObj = object > > ...and the compiler should know if that should be on heap or not. > > For me, every object is a "dynamic" instance. I don't work with records. > I think a programmer should know what happens. See for example how slow LLVM-optimizer and compiler are. One reason is the excessive use of "advanced" C++ technics in the LLVM tools. Step through the code and check what happens behind the scene in almost every statement, it is crazy. > > Another questions: > > 1. "Methods can be virtual, interfaces are listed after the possible > ancestor." obj6ty = object(obj5ty,testintf) [virtual] > method donothing() [virtual]; > end; > > Q: to make virtual methods , I need to declare the "object" [virtual] at > first? > Yes, or inherit from a virtual object. The purpose is that a virtual method table pointer in the data record will be reserved and initialized. The reason why to define it explicitely is also that IMO programmers should know what happens. > 2. "Virtual object not initialized with zeros." > obj4ty = object [virtual,nozeroinit] > private > ffield1: int32; > method getfield1(): int32; > method setfield1(const avalue: int32); > public > method dosomething() [virtual]; > property field1 read getfield1 write setfield1; > end; > > Q: What is the point about "nozeroinit"? What the advantages? > Performance. There is no need to zeroing the data if it is initialized in code anyway. > 3. Ancestor class: > > obj9ty = object(,testintf) [virtual] //no ancestor > > Q: Why this ugly syntax? You are simplifying some Pascal syntax (eg: > every line should have a ";", every block has an "end", etc) but here > you are committing a mistake, IMHO. > > If you allow this: > > obj4ty = object" << without ancestor > > you should allow this: > obj9ty = object(testintf) << not an acestor, but an interface > > ...and the compiler should know that is an interface, not a class. > For me code structures should always look the same. An object header is (ancestor,interface1,interface2...), I don't like to have an interface at the first position where normally the ancestor is placed. Martin ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
