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

Reply via email to