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
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.
1. "Methods can be virtual, interfaces are listed after the possible ancestor."
obj6ty = object(obj5ty,testintf) [virtual]
method donothing() [virtual];
Q: to make virtual methods , I need to declare the "object" [virtual] at first?
2. "Virtual object not initialized with zeros."
obj4ty = object [virtual,nozeroinit]
method getfield1(): int32;
method setfield1(const avalue: int32);
method dosomething() [virtual];
property field1 read getfield1 write setfield1;
Q: What is the point about "nozeroinit"? What the advantages?
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.
>> I'm following and participate (more or less) of a new language called
>> EO https://github.com/yegor256/eo that do not have classes, NULL and
>> other things that should not exists in OOP.
> That looks a little bit abstract to me. A general purpose programming language
> should be handy and not necessarily academically clean.
I pointed this project as an example about concepts that are truly
object-oriented. One of them is: no class, just objects.
I tried to propose a more Pascalish syntax, but they didn't accept all
my ideas, unfortunately.
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