On Sun, May 7, 2017 at 4:15 PM, Martin Schreiber <mse00...@gmail.com> wrote: > 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(); > "
Two ways to define the same thing. Do you think this is good? > One does not need to use "class", it can be removed. I thought that people > comming from Free Pascal will like it. ;-) You could be right, but I think they will like more if not exist ambiguity. :) >> 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. I understand. But what about create a simple and default syntax/design to the most developers and theirs simple applications and, at the same time, provide some "options" like "annotations" (or some like that) to the "hackers" that need 100% performance? >> >> 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. IMO this is too verbose. >> 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. Well, Ok. This matches I'm talking above: annotations for hackers. >> 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. So, is not better to do this? 1. obj4ty = object(tobject) 2. obj9ty = object(tobject, testintf) I mean, we always need to write the ancestor. It will always look the same. Marcos Douglas ------------------------------------------------------------------------------ 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
