Re: [MSEide-MSEgui-talk] MSElang Objects

[Marcos Douglas B. Santos]

On Tue, May 9, 2017 at 10:52 AM, Martin Schreiber  wrote:
> On Tuesday 09 May 2017 15:26:24 Marcos Douglas B. Santos wrote:
>>
>> It is not about if these languages are better, but if they are easy to
>> do the work.
>>
> Thats the reason why I proposed the additional and possibly redundant "class".
> You are against the "class" which eliminates the explicit "^" dereference and
> you are against the "^" which eliminates the uncertainty of value/reference
> object item access with the same notation. :-)

Because I thought that was possible to have just one notation using
"object".  :)
Let's think more about it...


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 Tuesday 09 May 2017 15:26:24 Marcos Douglas B. Santos wrote:
>
> It is not about if these languages are better, but if they are easy to
> do the work.
>
Thats the reason why I proposed the additional and possibly redundant "class". 
You are against the "class" which eliminates the explicit "^" dereference and 
you are against the "^" which eliminates the uncertainty of value/reference 
object item access with the same notation. :-)

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 Tue, May 9, 2017 at 10:00 AM, Martin Schreiber  wrote:
> On Tuesday 09 May 2017 14:08:39 Marcos Douglas B. Santos wrote:
>>
>> I understand your point of view but I think this could be confusing...
>> Well, first of all we should understand the proposal this new language:
>>
>> 1. Is it a low level language that will works like C to make libs, OS and
>> so on? 2. Is it a high level language that abstract the details, but allow
>> us to use these details *if* we wish?
>>
>> I see Object Pascal inside second option.
>>
> Me too, but "abstract details" and "hide details" is not the same for me.
> Agreed, if a developer is confused about pointers and copying
> contents/references he/she should not use MSElang nor Free Pascal.

It is not about "confused" because the developer do not know how to do
something. It is about how easier is to code something in such
language.
If I need to code some lib that will be use in a very specific
condition, low memory, etc I *need* to know how work with low level
code to make a good project. But I wouldn't like to think in these
stuff every day, if my work (for example) is making desktop forms or
web applications which work with a database.
I think this is the one of motives that developers choose PHP for Web,
Object Pascal (MSE, Delphi or Lazarus) for Desktop, C# if the company
use all Microsoft and so on.

It is not about if these languages are better, but if they are easy to
do the work.

Regards,
Marcos Douglas

PS: For me Object Pascal is the best language, because I can make low
level applications, awesome Desktop applications, everything is
cross-compiled and now working with a big Web application which have
an excellent performance (even if I do not thinking so much on it),
good modularization and maintenance... everything in just one
language... and the f* JavaScript.

--
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 Tuesday 09 May 2017 14:08:39 Marcos Douglas B. Santos wrote:
>
> I understand your point of view but I think this could be confusing...
> Well, first of all we should understand the proposal this new language:
>
> 1. Is it a low level language that will works like C to make libs, OS and
> so on? 2. Is it a high level language that abstract the details, but allow
> us to use these details *if* we wish?
>
> I see Object Pascal inside second option.
>
Me too, but "abstract details" and "hide details" is not the same for me. 
Agreed, if a developer is confused about pointers and copying 
contents/references he/she should not use MSElang nor Free Pascal.

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 Tue, May 9, 2017 at 3:24 AM, Martin Schreiber  wrote:
> On Monday 08 May 2017 22:44:39 Marcos Douglas B. Santos wrote:
>> On Mon, May 8, 2017 at 4:05 PM, Sieghard  wrote:
>> > Hallo Marcos,
>> >
>> > Du schriebst am Mon, 8 May 2017 13:12:19 -0300:
>> >> >> 2. In this case:
>> >> >>  obj2: ^objty; //on heap
>> >> >>
>> >> >> Is it possible to remove the "^"?
>> >> >> obj2.f1:= 123;
>> >> >
>> >> > No, obj2 is a pointer.
>> >> >
>> >> >> I think this distinction exists because "class" exists, right?
>> >
>> > How does that behave in case of _nested objects_, possibly with
>> > identically named fields, which might even be of different types? Is that
>> > manageable, or will the construct break down, at least on "pathological"
>> > casses?
>> >
>> > (I'm afraid it _will_ break down.)
>>
>> For me it would be the same as today, using classes.
>
> But classes always are a pointer to a memory area on heap. Objects can be in
> global static memory, on stack or on heap so I think it should be visible at
> element access if the object reference is an address or the content.
> "
> type
>  tcla = class
>  end;
>  objty = object
>   f1: int32;
>  end;
>  pobjty = ^objty;
>
> var
>  cla1: tcla;
>  cla2: tcla;
>  obj1: objty;
>  obj2: objty;
>  obj3: ^objty; //or pobjty
>  obj4: ^objty; //or pobjty
> begin
>  obj1: objty;
>  cla1:= cla2; //copies the address of content
>  obj1:= obj2; //copies the content
>  obj1.f1:= 123;
>  obj3:= obj4; //copies the address of content
>  obj3:= @obj2;//copies the address of content
>  obj3^.f1:= 123;
>   //or
>  with o: obj3^ do
>   o.f1:= 123;
>  end;

I understand your point of view but I think this could be confusing...
Well, first of all we should understand the proposal this new language:

1. Is it a low level language that will works like C to make libs, OS and so on?
2. Is it a high level language that abstract the details, but allow us
to use these details *if* we wish?

I see Object Pascal inside second option.

>> But Martin have already disagreed about this single syntax.
>>
> I must work some time with "object"s in order to decide if an
> additional "class" type is rectified.

Sounds good.


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 Tuesday 09 May 2017 10:41:00 Fred van Stappen wrote:
> Hello.
>
>
> If I may give my HO, I see more future for libraries than for executables
> for Pascal.
>
>
> So I hope that mselang will take (much more) care for the size and speed of
> libraries than fpc does.
>
MSElang uses LLVM to produce the binaries so I assume if you get good results 
with Clang you will get good results with MSElang too.
>
> It is sad that still a fpc library with same code is 5 times bigger than a
> fpc executable ( and montain times bigger than same C code compiled with
> gcc or clang).
>
Do you know why?
>
> I ask it regularly to fpc forum but (still same answer for more than 15
> years now !) ---> "It is on the todo list".
>
>
> fpc libraries can be compiled for Java-native-libraries too.
>
>
> I have to confess also that my plan are to use Pascal only for creating
> libraries (and Java for the rest).
>
Why? Doesn't this make debugging much more difficult?

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

[Fred van Stappen]

Hello.


If I may give my HO, I see more future for libraries than for executables for 
Pascal.


So I hope that mselang will take (much more) care for the size and speed of 
libraries than fpc does.


It is sad that still a fpc library with same code is 5 times bigger than a fpc 
executable ( and montain times bigger than same C code compiled with gcc or 
clang).


I ask it regularly to fpc forum but (still same answer for more than 15 years 
now !) ---> "It is on the todo list".


fpc libraries can be compiled for Java-native-libraries too.


I have to confess also that my plan are to use Pascal only for creating 
libraries (and Java for the rest).


Fre;D





--
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 Monday 08 May 2017 22:44:39 Marcos Douglas B. Santos wrote:
> On Mon, May 8, 2017 at 4:05 PM, Sieghard  wrote:
> > Hallo Marcos,
> >
> > Du schriebst am Mon, 8 May 2017 13:12:19 -0300:
> >> >> 2. In this case:
> >> >>  obj2: ^objty; //on heap
> >> >>
> >> >> Is it possible to remove the "^"?
> >> >> obj2.f1:= 123;
> >> >
> >> > No, obj2 is a pointer.
> >> >
> >> >> I think this distinction exists because "class" exists, right?
> >
> > How does that behave in case of _nested objects_, possibly with
> > identically named fields, which might even be of different types? Is that
> > manageable, or will the construct break down, at least on "pathological"
> > casses?
> >
> > (I'm afraid it _will_ break down.)
>
> For me it would be the same as today, using classes.

But classes always are a pointer to a memory area on heap. Objects can be in 
global static memory, on stack or on heap so I think it should be visible at 
element access if the object reference is an address or the content.
"
type
 tcla = class
 end;
 objty = object
  f1: int32;
 end;
 pobjty = ^objty;

var
 cla1: tcla;
 cla2: tcla;
 obj1: objty;
 obj2: objty;
 obj3: ^objty; //or pobjty
 obj4: ^objty; //or pobjty
begin
 obj1: objty;
 cla1:= cla2; //copies the address of content
 obj1:= obj2; //copies the content
 obj1.f1:= 123;
 obj3:= obj4; //copies the address of content
 obj3:= @obj2;//copies the address of content
 obj3^.f1:= 123;
  //or
 with o: obj3^ do
  o.f1:= 123;
 end;

> But Martin have already disagreed about this single syntax.
>
I must work some time with "object"s in order to decide if an 
additional "class" type is rectified.

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