Re: [MSEide-MSEgui-talk] MSElang Objects

[code dz]

btw the keyword (method) looks weird  , (sub) is much better or
typical pascal (procedure , function) . its only my opinion ;)

also the attribuates mechanism really looks cool .

seems the best dialect will born ;)

--
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

Re: [MSEide-MSEgui-talk] MSElang Objects

[Martin Schreiber]

On Sunday 07 May 2017 12:05:40 Graeme Geldenhuys wrote:
> On 2017-05-07 08:20, Martin Schreiber wrote:
> > MSElang and MSEpas (a subset of Free Pascal) have "string8" (utf-8)
> > "string16" (utf-16) "string32" (ucs-4)
>
> That sounds good.
>
> > and "bytestring" for any 8-bit encoding and
> > binary data.
>
> Why this? Why not simply Byte or an array of bytes. The term "bytestring"
> introduces confusion again.
>
Because of compatibility with string8 where the index base can be 1 and string 
concatenation.

> Also why bother with any other text encoding than the Unicode standard. The
> Unicode standard was designed to support ALL languages and finally get rid
> of the 8-bit mess. All you need is conversions from all the 8-bit encodings
> to Unicode, and then be done with it.
>
You probably never made software for bus systems and communication with 
hardware devices. There it often happens that bytestreams contain binary and 
text components. A reference counted buffer datatype which can be 
concatenated from strings and binary data is convenient and effective.

> >>Java makes this simple. One string type (class), one character type
> >> and 8 other primitive data types. Much simpler and easier to understand
> >> than the mess Object Pascal has, thanks to FPC and Delphi.
> >
> > MSElang has been designed as a high performance language so it can't be
> > so simple.
>
> Huh? Java is an excellent performance language. Please ignore all
> statements on the Internet older than say 5 years. The Java language has
> come a long way, and is *very* fast now. In fact, it actually generates
> binary code that is magnitudes faster than what FPC can achieve.

There are situations where 8 bit string code units are the best, there are 
others where 16 bit codeunits are appropriate and some where 32 bit codeunits 
provide the best performance. I like to control that myself instead to use an 
opaque string class.

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

Re: [MSEide-MSEgui-talk] MSElang Objects

[code dz]

>>
> I plan to use method attributes for operator overloading too:
> "
> type
>  complexty = object
>   real,imm: flo64;
>   method add(const a,b: complexty): complexty ['+'];
>   method sub(const a,b: complexty): complexty ['-'];
>   method mul(const a,b: complexty): complexty ['*'];
>   method tostring8(const source: complexty): string8 [':='];
>  end;
> "
>
> Martin

sounds good , but i think it add some complexity to the code
readability, because the name (add) already indicates the operation ,
so why ['+']  , maybe operator instead of method should be fine ! .
just thought

--
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

Re: [MSEide-MSEgui-talk] MSElang Objects

[Martin Schreiber]

On Sunday 07 May 2017 11:10:48 code dz wrote:
> btw the keyword (method) looks weird  , (sub) is much better or
> typical pascal (procedure , function) . its only my opinion ;)
>
I wanted to remove the distinction between "procedure" and "function", 
so "sub". Object procedures and functions have an implicit data pointer 
parameter ("self") so I thought that an own name ("method") is justified.
 
> also the attribuates mechanism really looks cool .
>
I plan to use method attributes for operator overloading too:
"
type
 complexty = object
  real,imm: flo64;
  method add(const a,b: complexty): complexty ['+'];
  method sub(const a,b: complexty): complexty ['-'];
  method mul(const a,b: complexty): complexty ['*'];
  method tostring8(const source: complexty): string8 [':='];
 end;
"

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

Re: [MSEide-MSEgui-talk] MSElang Objects

[code dz]

congratulation :)
what about the rtl , would you uses fpc one of write your own ?

--
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

Re: [MSEide-MSEgui-talk] MSElang Objects

[Martin Schreiber]

On Sunday 07 May 2017 11:01:40 code dz wrote:
> congratulation :)
> what about the rtl , would you uses fpc one of write your own ?
>
MSElang itself will only have a minimal RTL. For "daily business tasks" we 
have the MSEgui environment already.

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

Re: [MSEide-MSEgui-talk] MSElang Objects

[Graeme Geldenhuys]

On 2017-05-07 08:20, Martin Schreiber wrote:
> MSElang and MSEpas (a subset of Free Pascal) have "string8" (utf-8) 
> "string16" 
> (utf-16) "string32" (ucs-4)

That sounds good.


> and "bytestring" for any 8-bit encoding and 
> binary data.

Why this? Why not simply Byte or an array of bytes. The term "bytestring"
introduces confusion again.

Also why bother with any other text encoding than the Unicode standard. The
Unicode standard was designed to support ALL languages and finally get rid
of the 8-bit mess. All you need is conversions from all the 8-bit encodings
to Unicode, and then be done with it.


>>Java makes this simple. One string type (class), one character type and
>> 8 other primitive data types. Much simpler and easier to understand than
>> the mess Object Pascal has, thanks to FPC and Delphi.
>>
> MSElang has been designed as a high performance language so it can't be so 
> simple.

Huh? Java is an excellent performance language. Please ignore all statements
on the Internet older than say 5 years. The Java language has come a long way, 
and
is *very* fast now. In fact, it actually generates binary code that is
magnitudes faster than what FPC can achieve. I've recently proved this in
the Lazarus Forum, and no amounts of "tweaks" or obscure coding methods in
Object Pascal or FPC compiler options could come close to the performance I
saw in Java 8.


Regards,
  Graeme

-- 
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

My public PGP key:  http://tinyurl.com/graeme-pgp

--
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

Re: [MSEide-MSEgui-talk] MSElang Objects

[code dz]

2017-05-07 12:01 UTC+01:00, Martin Schreiber :
> On Sunday 07 May 2017 12:11:06 code dz wrote:
>>
>> sounds good , but i think it add some complexity to the code
>> readability, because the name (add) already indicates the operation ,
>> so why ['+']  , maybe operator instead of method should be fine ! .
>> just thought
>>
> The method names can be choosen freely:
> "
>  complexty = object
>   real,imm: flo64;
>   method add(const a,b: complexty): complexty ['+'];
>   method sub(const a,b: complexty): complexty ['-'];
>   method mulblabla(const a,b: complexty): complexty ['*'];
>   method tostring8(const source: complexty): string8 [':='];
>   method tostring16(const source: complexty): string16 [':='];
>  end;
>
>  complex2ty object(complexty)
>   scale: flo64;
>   method addscaled(const a,b: complexty): complexty ['+'];
>   method subscaled(const a,b: complexty): complexty ['-'];
>  end;
> "
> so "operator" instead of an attachment would not work.
> "
>  complexty = object
>   real,imm: flo64;
>   operator add(const a,b: complexty): complexty;
>   operator sub(const a,b: complexty): complexty;
>   operator mulblabla(const a,b: complexty): complexty;
>   operator tostring8(const source: complexty): string8;
>   operator tostring16(const source: complexty): string16;
>  end;
>
>  complex2ty object(complexty)
>   scale: flo64;
>   operator addscaled(const a,b: complexty): complexty;
>   operator subscaled(const a,b: complexty): complexty;
>  end;
> "
> Also
> "
>   method add(const a,b: complexty): complexty ['+'];
> "
> can be used as ordinary object method so I don't think it should be
> named "operator".
>
> "
> method complexty.add(const a,b: complexty): complexty;
> begin
>  result.real:= a.real + b.real;
>  result.imm:= a.imm + b.imm;
> end;
>
> var
>  a,b,c: complexty;
> [...]
>  a:= b + c;
>  a:= add(b,c);
> "
>
> Martin
>

good points , you are right then

--
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

Re: [MSEide-MSEgui-talk] MSElang Objects

[Marcos Douglas B. Santos]

On Sat, May 6, 2017 at 11:33 AM, Martin Schreiber  wrote:
>> Use only objects and change this syntax...
>> o1: ^obj5ty;
>> ...to this one
>> o1: obj5ty;
>>
> Correct. Plus o1^.f1 <-> c1.f1 for access of heap instance elements and
> that "class" instances always are on heap.
> "class" is for people who are accustomed to Free Pascal. Do you think "class"
> should be removed?

I think every language should be as simple as possible.
So, if you can mix every Pascal concept in just one concept, called
object, it is better.

But if you care about programmers that came from another language and
you care if they are confortable using the same concepts they have in
another languages, it is up to you decide if it worth continue with
this concepts.

Classes should not exists in object-oriented programming. This is a
mistake. Only objects should exists.
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.

Best regards,
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

Re: [MSEide-MSEgui-talk] MSElang Objects

[Marcos Douglas B. Santos]

On Sun, May 7, 2017 at 1:14 PM, Martin Schreiber  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.


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?

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?

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.

Best regards,
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

Re: [MSEide-MSEgui-talk] MSElang Objects

[Martin Schreiber]

On Sunday 07 May 2017 18:48:13 Marcos Douglas B. Santos wrote:
> On Sun, May 7, 2017 at 1:14 PM, Martin Schreiber  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

Re: [MSEide-MSEgui-talk] MSElang Objects

[Marcos Douglas B. Santos]

On Sun, May 7, 2017 at 7:05 AM, Graeme Geldenhuys
 wrote:
>> MSElang and MSEpas (a subset of Free Pascal) have "string8" (utf-8) 
>> "string16"
>> (utf-16) "string32" (ucs-4)
>
> That sounds good.

Why?
Is not it better to just use a single String type (as a class or not)
as you've said?

>> ...
>
> Huh? Java is an excellent performance language. Please ignore all statements
> on the Internet older than say 5 years. The Java language has come a long 
> way, and
> is *very* fast now. In fact, it actually generates binary code that is
> magnitudes faster than what FPC can achieve. I've recently proved this in
> the Lazarus Forum, and no amounts of "tweaks" or obscure coding methods in
> Object Pascal or FPC compiler options could come close to the performance I
> saw in Java 8.

...and because that and others, we start to think if Pascal will died
soon or if we will use Pascal to make bytecode to Java.  :|

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

Re: [MSEide-MSEgui-talk] MSElang Objects

[Marcos Douglas B. Santos]

On Sun, May 7, 2017 at 4:15 PM, Martin Schreiber  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  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