Re: [MSEide-MSEgui-talk] MSElang Objects

[Sieghard]

Hallo Martin,

Du schriebst am Wed, 14 Jun 2017 06:56:33 +0200:

> What is wrong with "method" instead of "object function"?

It's a new keyword, and it forgoes any distinction between real functions
and procedures. With an "object function", you can also have an "object
procedure". With "method", impossible.

> > [Pascal-ish "with"]
> Example:
...

> Now the author of the widget library adds a new property to "cwidget"
...
> and brakes the functionality of your "test()" procedure.

Well  you wanted to say that this _broke_ ("breaks") the code, i surmise.
Sure, if you _recompile_ it, it will use the new declarations. But the
modification should be _known_ from the unit documetation, and this has to
be taken into account anyway. The author of the widget library could just
as well have changed the "pos" field's type to something different, which
would break the derived code just as well.

But I _did_ say, "you might consider to do away with "WITH", as some even
say they consider it harmful."

-- 
-- 
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
---
Mit freundlichen Grüßen, S. Schicktanz
---



--
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 13 June 2017 22:29:21 Sieghard wrote:

> Using this as a reference, a syntax like
>
>   MethodType = object function ( or
>   MethodVariable: object function (
> might be considered. Yes, this is more typing.
> (Perhaps abbreviate it with just usind a (leading) period? Like
>  ".function (
What is wrong with "method" instead of "object function"?

>
> [Pascal-ish "with"]
>
> > The problem is that if there are members added to the referenced "with"
> > container they override elements with the same name and type in existing
> > code.
>
> Only if not explicitely qualified - you can always "break out" of the
> current scope using qualifiers. For the current object, the qualifier
> is always "self". And for elements outside of any object context, it is the
> unit name. What's your problem then? and how should the Modula variant be
> better in that respect?
>
Example:
"
unit widgets
interface
type
 pointty = record
  x,y: int32;
 end;

 cwidget = class()
  pos: pointty;
 end;
"

"
unit test
uses
 widgets;

procedure test();
var
 widget: cwidget;
 left: int32;
[...]
 with widget do
  pos.x:= left;
 end;
"

Now the author of the widget library adds a new property to "cwidget"
"
 cwidget = class()
  pos: pointty;
  property left: int32 read pos.x write pos.x;
 end;
"
and brakes the functionality of your "test()" procedure.

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

[Martin Schreiber]

On Tuesday 13 June 2017 17:27:41 Edson H wrote:
> Ok. I understand what Martin does. I have implemented this syntax too, in
> my compiler.
>
>
> I just was asking for the keyword ELSIF, to avoid nested IF, for several
> comparisons, but Martin prefers to have a lot of THEN ... END, nested. I
> think the best way is to include ELSIF, to have a clear syntax (like
> Modula-2):
>
>
> IF ... THEN
>
>
> ELSIF ... THEN
>
>
> ELSIF ... THEN
>
>
> END;
>
>
> And that's how it's implemented in my compiler, so it's compatible with
> MSElang, except that MSElang doesn't support ELSIF.
>
It can be added to MSElang too, not yet decided.

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

[Sieghard]

Hallo Martin,

Du schriebst am Tue, 13 Jun 2017 06:47:58 +0200:

> > [functions & procedures]
> IIRC you proposed to use "function" for both? Sometimes I have the

No. I did propose to use "function" _only_ if you _insisted_ to use the
same keyword for both uses. If you kept the Pascal convention, only the
better, I will _not_ protest.

["of object"]
> I probably understand wrong, but do "SomeObjectMethod" 
> and "SomeMethodVariable" work with "SomeObject" only? That's not how
> Delphi and MSElang method variables work.

A method variable requires a specific "signature", i.e. parameter list,
which belongs to a method of some specific object type. But I see your case
- for commonly occurring signatures it might be desirable to define such
variables independently of the destination type.
On the other hand, I would really prefer some other syntax than this
appendix, something more in line with the object declaration syntax.
Even the Delphi creators themselves seem not to be happy with it, since
they invented a completely different way for their later introduced "class
methods".
Using this as a reference, a syntax like

  MethodType = object function ( > [WITH]
> > > MSElang provides a safe "with" statement with mandatory local
> > > qualifier.  
> >
> > Something like the "Modula" version?
> > I.e. effectively variable (object) renaming, without opening a new
> > scope?  
> 
> Yes.

[Pascal-ish "with"]
> The problem is that if there are members added to the referenced "with" 
> container they override elements with the same name and type in existing 
> code.

Only if not explicitely qualified - you can always "break out" of the
current scope using qualifiers. For the current object, the qualifier
is always "self". And for elements outside of any object context, it is the
unit name. What's your problem then? and how should the Modula variant be
better in that respect?

> > > [...]
> > > > > It has the advantage that procedure and method names are aligned.
> > > > > More  
> > > >
> > > > That _might_ be a disadvantage at times, as it might make reading
> > > > the source text more difficult.  
> > >
> > > Please explain.  
> >
> > Citing you in
...
> > It looks ugly.
> > "
> > You said.
> >  
> That's not "it might make reading the source text more difficult".

Yes, it is. When something "looks ugly" on first sight, it already _has_
distracted you from understanding what it _means_. You have to concentrate
on the text explicitely to understand it, may be have to read it again. 
And above that, reading a, possibly long, list of all similar looking
lines, it is not so easy to spot changes in those neatly aligned parts.
(Which might be the reason that it "looks ugly".)

-- 
-- 
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
---
Mit freundlichen Grüßen, S. Schicktanz
---



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

[Edson H]

Ok. I understand what Martin does. I have implemented this syntax too, in my 
compiler.


I just was asking for the keyword ELSIF, to avoid nested IF, for several 
comparisons, but Martin prefers to have a lot of THEN ... END, nested. I think 
the best way is to include ELSIF, to have a clear syntax (like Modula-2):


IF ... THEN


ELSIF ... THEN


ELSIF ... THEN


END;


And that's how it's implemented in my compiler, so it's compatible with 
MSElang, except that MSElang doesn't support ELSIF.




De: Marcos Douglas B. Santos <m...@delfire.net>
Enviado: domingo, 11 de junio de 2017 08:11 p.m.
Para: General list for MSEide+MSEgui
Asunto: Re: [MSEide-MSEgui-talk] MSElang Objects


On Sun, Jun 11, 2017 at 4:58 PM, Edson H 
<dev_nul...@hotmail.com<mailto:dev_nul...@hotmail.com>> wrote:

No so much, but In Pascal you need to do:


if ... then
  begin  //WARNING: If use more than a sentence, you need BEGIN-END
...
  end  //DANGER: Don't put semicolon!
else if ... then
  begin  //WARNING: If use more than a sentence, you need BEGIN-END
  ...
  end  //DANGER: Don't put semicolon!
else
  begin  //WARNING: the same before.
   //some code
  end;  //DANGER: Put semicolon!


You're right about classic Pascal. I agree that is ugly.
However, Martin is fixing this, always putting a semicolon no matter what. 
Besides that, the "begin" doesn't exists anymore, just "end". In other words, 
we will always have a "block" using if-then-end instead of if-then-begin-end.

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 Monday 12 June 2017 22:13:32 Sieghard wrote:
> Hallo Martin,
>
> [functions & procedures]
>
> > "function" in C always has a type identifier. As you write, a
> > mathematical function returns something. So "procedure" like in Wirth's
> > Modula2.
>
> Or so. In any case, you lose the ability to immediately recognize whether
> such a thing can be used in an expression (returning a value) or has to be
> used standing alone (classical Pascal "PROCEDURE").

IIRC you proposed to use "function" for both? Sometimes I have the impression 
you are against anything.

> Yes, that _is_ ugly. But it is never needed within the context of an
> object, it is _only_ used (needed) for the declaration of a type referring
> to an object method. You could just as well specify the containing object
> type as a qualifier, like this:
>
>   SomeObjectMethod = SomeObject.procedure (a, b: int32);
>
> or, like your example, which defines the type only implicitely:
>
>   ObjectMethodVariable: SomeObject.procedure (a, b: int32);
>
> if it refers to a method of a different object type, or just omit the
> qualifier if it refers to the currently defined object type. I think this
> should be unmistakable.
>
I probably understand wrong, but do "SomeObjectMethod" 
and "SomeMethodVariable" work with "SomeObject" only? That's not how Delphi 
and MSElang method variables work.

> [WITH]
>
> > MSElang provides a safe "with" statement with mandatory local qualifier.
>
> Something like the "Modula" version?
> I.e. effectively variable (object) renaming, without opening a new scope?

Yes.

> I definitely dislike this kind. This aliasing makes reading the code much
> more difficult than the Pascal version of "WITH".

Maybe MSElang will support this version too, not yet decided.

> The Modula variant might reduce typing a bit, because the alias names can
> be shorter, but it still requires explicit qualification of each
> identifier, whereas the Pascal variant, while still stating each referred
> object instance, completely does away with qualification where the
> reference is unique and still allows for explicit resolution if conflicts
> can occur.
>
You probably know what the problem with the Pascal variant is, don't you?. 
IIRC you even wrote about it:
"
> Alternatively, you might consider to do
> away with "WITH", as some even say they consider it harmful.
"
The problem is that if there are members added to the referenced "with" 
container they override elements with the same name and type in existing 
code.

> > [...]
> >
> > > > It has the advantage that procedure and method names are aligned.
> > > > More
> > >
> > > That _might_ be a disadvantage at times, as it might make reading the
> > > source text more difficult.
> >
> > Please explain.
>
> Citing you in "<201706101259.59446.mse00...@gmail.com>":
> > "
> > proc test1(a: int32): flo64;
> > proc test2(const a: string8);
> > meth objty.test3(a: int32): flo64;
> > meth objty.test4(const a: string8);
> > meth ctest.test3(a: int32): flo64;
> > meth ctest.test4(const a: string8);
> > "
> > It has the advantage that procedure and method names are aligned. More
> > experiments are needed.
>
> It looks ugly.
> "
> You said.
>
That's not "it might make reading the source text 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

[Martin Schreiber]

On Sunday 11 June 2017 02:36:46 Sieghard wrote:
> Hallo Martin,
>
> Du schriebst am Sat, 10 Jun 2017 06:54:15 +0200:
> > I don't like "sub" much but found nothing better up to now. I think that
>
> "sub" seems to me to imply you're about to create a new BASIC variant.
> Why not use "function" for all such things, if you don't like to
> explicitely state that some won't return a value. Looks like C then,
> but Delphi and fpc allow for discarding a return value already anyway.
> The separate names of Wirth's Pascal _did_ have a reason, and that was to
> discern between real functions, which ought to _only_ calculate something
> and return the result of the calculation, like a mathematical function
> does, and a multiply used sequence of commands that produce a "side
> effect", something the programm doesn't really need internally, but that
> provides "useful" information for its environment (e.g. the user).
> Considering the implementation of "VAR" parameters, i.e. parameters that
> can transport a value from within a procedure to its program surroundings,
> this difference has been blurred quite a lot by careless use(ers).
>
"function" in C always has a type identifier. As you write, a mathematical 
function returns something. So "procedure" like in Wirth's Modula2.

> > object methods deserve an own token "method" because of the implicit
> > "self" parameter.
>
> This _might_ be considered a valid argument, except that _any_ method
> _must_ always be specified in conjunction with its containing object so
> that there shouldn't be room for uncertainty.

A "method" combines a code address and a data pointer which is different 
from "procedure" which is a code address only. "method" also eliminates the 
need of the ugly
"
var
 meth1: procedure (a,b: int32) of object;
"
construct.
  
> You might argue with "WITH" 
> here, but even that is strictly defined in Pascal as to imply the scope of
> the referenced object as the outermost one, and therefore has to be used
> in case of multiple candidates. Alternatively, you might consider to do
> away with "WITH", as some even say they consider it harmful. You should
> remember, though, that this may mean a lot more typing (all those
> qualifiers that are otherwise implied).
>
MSElang provides a safe "with" statement with mandatory local qualifier.

[...]

> > It has the advantage that procedure and method names are aligned. More
>
> That _might_ be a disadvantage at times, as it might make reading the
> source text more difficult.
>
Please explain.

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

[Martin Schreiber]

On Sunday 11 June 2017 16:58:23 Marcos Douglas B. Santos wrote:
> On Sun, Jun 11, 2017 at 1:29 AM, Martin Schreiber  
wrote:
> >> You need to have a return. If you have a object with a method "exec",
> >> eg, why not return the object itself? Just return something.
> >
> > Why?
>
> Because you could write a more elegant code.
> If you return "self" even in methods that don't need to specify a
> return, you can codify using a style more declarative instead of a
> procedural style.
>
> Instead of this:
> ---
> obj.exec;
> obj.foo;
> obj.bar;
> ---
>
> We can do this:
> ---
> obj.exec.foo.bar;
> ---
>
I don't like it. Now one has to check what obj.exec() returns, what 
obj.exec.foo() returns and so on while reading th code. Another concern is 
performance.

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

[Martin Schreiber]

On Sunday 11 June 2017 17:31:33 Edson H wrote:
> It's strange. Do you prefer to write?
>
>
> if ... then
>
>   ...
>
> else
>
>   if ... then
>
> ...
>
>   else
>
> if ... then
>
>   ...
>
> else
>
>   ...
>
> end;
>
>   end;
>
> end;
>
>
> Instead of?
>
>
> if ... then
>
>   ...
>
> elsif ... then
>
>   ...
>
> elsif ... then
>
>   ...
>
> else
>
>   ...
>
> end;
>
Yes.

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, Jun 11, 2017 at 4:58 PM, Edson H  wrote:

> No so much, but In Pascal you need to do:
>
>
> if ... then
>   begin  //WARNING: If use more than a sentence, you need BEGIN-END
> ...
>   end  //DANGER: Don't put semicolon!
> else if ... then
>   begin  //WARNING: If use more than a sentence, you need BEGIN-END
>   ...
>   end  //DANGER: Don't put semicolon!
> else
>   begin  //WARNING: the same before.
>//some code
>   end;  //DANGER: Put semicolon!
>
>
You're right about classic Pascal. I agree that is ugly.
However, Martin is fixing this, always putting a semicolon no matter what.
Besides that, the "begin" doesn't exists anymore, just "end". In other
words, we will always have a "block" using if-then-end instead of
if-then-begin-end.

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

[Edson H]

No so much, but In Pascal you need to do:


if ... then
  begin  //WARNING: If use more than a sentence, you need BEGIN-END
...
  end  //DANGER: Don't put semicolon!
else if ... then
  begin  //WARNING: If use more than a sentence, you need BEGIN-END
  ...
  end  //DANGER: Don't put semicolon!
else
  begin  //WARNING: the same before.
   //some code
  end;  //DANGER: Put semicolon!




De: Marcos Douglas B. Santos <m...@delfire.net>
Enviado: domingo, 11 de junio de 2017 03:51 p.m.
Para: General list for MSEide+MSEgui
Asunto: Re: [MSEide-MSEgui-talk] MSElang Objects

On Sun, Jun 11, 2017 at 12:31 PM, Edson H <dev_nul...@hotmail.com> wrote:
>
> Instead of?
>
> if ... then
>   ...
> elsif ... then
>   ...
> elsif ... then
>   ...
> else
>   ...
> end;
>
>
> Don't see this like nested IF. It's just a multiple conditional. More at the 
> style of Modula-2 and the new language syntax.

Do you think that there are any difference — semantically speaking —
between your code and my below?
I'm using just Pascal...

---
> if ... then
>   ...
> else if ... then
>   ...
> else if ... then
>   ...
> else
>   ...
> end;
---

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
mseide-msegui-talk Info Page - 
SourceForge<https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk>
lists.sourceforge.net
mseide-msegui-talk -- General list for MSEide+MSEgui About mseide-msegui-talk


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

[Sieghard]

Hallo Martin,

Du schriebst am Sat, 10 Jun 2017 06:54:15 +0200:

> I don't like "sub" much but found nothing better up to now. I think that 

"sub" seems to me to imply you're about to create a new BASIC variant.
Why not use "function" for all such things, if you don't like to
explicitely state that some won't return a value. Looks like C then,
but Delphi and fpc allow for discarding a return value already anyway.
The separate names of Wirth's Pascal _did_ have a reason, and that was to
discern between real functions, which ought to _only_ calculate something
and return the result of the calculation, like a mathematical function does,
and a multiply used sequence of commands that produce a "side effect",
something the programm doesn't really need internally, but that provides
"useful" information for its environment (e.g. the user).
Considering the implementation of "VAR" parameters, i.e. parameters that
can transport a value from within a procedure to its program surroundings,
this difference has been blurred quite a lot by careless use(ers).

> object methods deserve an own token "method" because of the implicit
> "self" parameter.

This _might_ be considered a valid argument, except that _any_ method
_must_ always be specified in conjunction with its containing object so
that there shouldn't be room for uncertainty. You might argue with "WITH"
here, but even that is strictly defined in Pascal as to imply the scope of
the referenced object as the outermost one, and therefore has to be used
in case of multiple candidates. Alternatively, you might consider to do
away with "WITH", as some even say they consider it harmful. You should
remember, though, that this may mean a lot more typing (all those
qualifiers that are otherwise implied).

> "self" parameter. Comming from a Pascal background "procedure" implies
> that there must be a "function" too but there is none in MSElang. Maybe

That's the case with Pascal, but even "some" Pascal dialects allow using
"function" for the purpose of both, rendering "procedure" virtually
unneccessary.

> "proc" instead of "sub" and "meth" instead of "method" what do you think?

"Meth" might bring you some interesting new contacts that you might not
find desirable, being the name of a "designer drug".

> It has the advantage that procedure and method names are aligned. More 

That _might_ be a disadvantage at times, as it might make reading the
source text more difficult.

-- 
-- 
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
---
Mit freundlichen Grüßen, S. Schicktanz
---



--
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, Jun 11, 2017 at 12:31 PM, Edson H  wrote:
>
> Instead of?
>
> if ... then
>   ...
> elsif ... then
>   ...
> elsif ... then
>   ...
> else
>   ...
> end;
>
>
> Don't see this like nested IF. It's just a multiple conditional. More at the 
> style of Modula-2 and the new language syntax.

Do you think that there are any difference — semantically speaking —
between your code and my below?
I'm using just Pascal...

---
> if ... then
>   ...
> else if ... then
>   ...
> else if ... then
>   ...
> else
>   ...
> end;
---

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

[Edson H]

It's strange. Do you prefer to write?


if ... then

  ...

else

  if ... then

...

  else

if ... then

  ...

else

  ...

end;

  end;

end;


Instead of?


if ... then

  ...

elsif ... then

  ...

elsif ... then

  ...

else

  ...

end;


Don't see this like nested IF. It's just a multiple conditional. More at the 
style of Modula-2 and the new language syntax.



De: Martin Schreiber <mse00...@gmail.com>
Enviado: domingo, 11 de junio de 2017 07:21 a.m.
Para: mseide-msegui-talk@lists.sourceforge.net
Asunto: Re: [MSEide-MSEgui-talk] MSElang Objects

On Saturday 10 June 2017 17:39:14 Edson H wrote:
>
> By the way, I haven't seen the keyword ELSIF in your IF syntax.
>
MSElang has no "elsif". I think nested structures should be written so that
the nested character is visible.

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
mseide-msegui-talk Info Page - 
SourceForge<https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk>
lists.sourceforge.net
mseide-msegui-talk -- General list for MSEide+MSEgui About mseide-msegui-talk


--
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, Jun 11, 2017 at 1:29 AM, Martin Schreiber  wrote:
>> You need to have a return. If you have a object with a method "exec",
>> eg, why not return the object itself? Just return something.
>
> Why?

Because you could write a more elegant code.
If you return "self" even in methods that don't need to specify a
return, you can codify using a style more declarative instead of a
procedural style.

Instead of this:
---
obj.exec;
obj.foo;
obj.bar;
---

We can do this:
---
obj.exec.foo.bar;
---

Looks nothing, but imagine that you give a instance from another object.
If these methods (exec, foo, and bar) do not return "self", you need
to declarate a variable — or use "with".

So:
---
obj := x.getAnObject;
obj.exec;
obj.foo;
obj.bar;
---

But if you return "self":
---
x.getAnObject
  .exec
  .foo
  .bar;
---

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 Saturday 10 June 2017 17:39:14 Edson H wrote:
>
> By the way, I haven't seen the keyword ELSIF in your IF syntax.
>
MSElang has no "elsif". I think nested structures should be written so that 
the nested character is visible.

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 Sat, Jun 10, 2017 at 1:54 AM, Martin Schreiber  wrote:
>
> I don't like "sub" much but found nothing better up to now. I think that
> object methods deserve an own token "method" because of the implicit "self"
> parameter. Comming from a Pascal background "procedure" implies that there
> must be a "function" too but there is none in MSElang. Maybe "proc" instead
> of "sub" and "meth" instead of "method" what do you think?

My "vote" is to use "function" anywhere.

You've said:

> ...object methods deserve an own token "method" because of the implicit 
> "self" parameter.

But the object itself is a context to the functions (methods) so, I
can't see any problems.

About the procedures vs functions vs "sub"... well, as I've said, just
use "function".
If you have a return, use the same as Pascal:
function Foo: Boolean;

If you don't have a return, don't write the last part:
function Foo;

IMHO a function that doesn't have a return — doesn't matter if is a
method or a "sub" — isn't a good design.
You need to have a return. If you have a object with a method "exec",
eg, why not return the object itself? Just return something.
But, for procedural programmers, just don't write the last part as I proposed.

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

[Edson H]

OK. I will implement the same: PROCEDURE (procedures and functions) and METHOD 
(procedure and functions for objects).


I have implemented the mode {$mode pascal} too, for Pascal compatibility. The 
default is {$mode PicPas}.


By the way, I haven't seen the keyword ELSIF in your IF syntax.


De: Martin Schreiber <mse00...@gmail.com>
Enviado: sábado, 10 de junio de 2017 10:59 a.m.
Para: mseide-msegui-talk@lists.sourceforge.net
Asunto: Re: [MSEide-MSEgui-talk] MSElang Objects

On Saturday 10 June 2017 06:54:15 Martin Schreiber wrote:
> "
> proc test1(a: int32): flo64;
> proc test2(const a: string8);
> meth objty.test3(a: int32): flo64;
> meth objty.test4(const a: string8);
> meth ctest.test3(a: int32): flo64;
> meth ctest.test4(const a: string8);
> "
> It has the advantage that procedure and method names are aligned. More
> experiments are needed.
>
It looks ugly. Currently I think "method" and "procedure" as you propose is
better.
"
 procedure test1(a: int32): flo64;
 procedure test2(const a: string8);
 method objty.test3(a: int32): flo64;
 method objty.test4(const a: string8);
 method ctest.test3(a: int32): flo64;
 method ctest.test4(const a: string8);
"

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
mseide-msegui-talk Info Page - 
SourceForge<https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk>
lists.sourceforge.net
mseide-msegui-talk -- General list for MSEide+MSEgui About mseide-msegui-talk


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

ah , i didn't knew this

--
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 Saturday 10 June 2017 14:21:45 code dz wrote:
> i think (method) is good abridgement for both function & procedure .
> why another keyword!
>
Because a method has an implicit "self" parameter which "procedure" 
and "function" don't have.

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 think (method) is good abridgement for both function & procedure .
why another keyword!

--
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 Saturday 10 June 2017 06:54:15 Martin Schreiber wrote:
> "
> proc test1(a: int32): flo64;
> proc test2(const a: string8);
> meth objty.test3(a: int32): flo64;
> meth objty.test4(const a: string8);
> meth ctest.test3(a: int32): flo64;
> meth ctest.test4(const a: string8);
> "
> It has the advantage that procedure and method names are aligned. More
> experiments are needed.
>
It looks ugly. Currently I think "method" and "procedure" as you propose is 
better.
"
 procedure test1(a: int32): flo64;
 procedure test2(const a: string8);
 method objty.test3(a: int32): flo64;
 method objty.test4(const a: string8);
 method ctest.test3(a: int32): flo64;
 method ctest.test4(const a: string8);
"

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

[Martin Schreiber]

On Saturday 10 June 2017 07:52:31 Edson H wrote:
> I was thinking in using the two forms:
>
>
> "proc" (short word) and "procedure" (long word).
>
> "meth" (short word) and "method" (long word).
>
>
> I would like to keep the PROCEDURE, in the honor of Pascal/Modula-2.
>
That contradicts the guideline that code allways should look the same. I just 
implemented dialect switching in MSElang, with {$mode pascal} the FPC objpas 
syntax can be used. "*.pas" and "*.pp" file use {$mode pascal} by 
default, "*.mla" use {$mode mselang}.

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

[Edson H]

Yes, I like "proc" and "meth", because i like the short words.


I was thinking in using the two forms:


"proc" (short word) and "procedure" (long word).

"meth" (short word) and "method" (long word).


I would like to keep the PROCEDURE, in the honor of Pascal/Modula-2.


I'm not implementing objects by the moment, so I'm not using "method". But I 
have consider to use the "method" keyword too, before knowing about MSElang.


I think, people who is developing Pascal compilers, must talk in order to 
create compatible syntax, the most possible.



De: Martin Schreiber <mse00...@gmail.com>
Enviado: sábado, 10 de junio de 2017 04:54 a.m.
Para: mseide-msegui-talk@lists.sourceforge.net
Asunto: Re: [MSEide-MSEgui-talk] MSElang Objects

On Saturday 10 June 2017 06:15:09 Edson H wrote:
> Hi Martin,
>
>
> I have seen you use "sub" for procedures or functions,  and "method" for
> object. Is it?
>
Yes.

> I think you can use only PROCEDURE keyword, for procedures and functions
> (and probably for objects), like Modula-2, do.
>
I don't like "sub" much but found nothing better up to now. I think that
object methods deserve an own token "method" because of the implicit "self"
parameter. Comming from a Pascal background "procedure" implies that there
must be a "function" too but there is none in MSElang. Maybe "proc" instead
of "sub" and "meth" instead of "method" what do you think?
"
proc test1(a: int32): flo64;
proc test2(const a: string8);
meth objty.test3(a: int32): flo64;
meth objty.test4(const a: string8);
meth ctest.test3(a: int32): flo64;
meth ctest.test4(const a: string8);
"
It has the advantage that procedure and method names are aligned. More
experiments are needed.


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
mseide-msegui-talk Info Page - 
SourceForge<https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk>
lists.sourceforge.net
mseide-msegui-talk -- General list for MSEide+MSEgui About mseide-msegui-talk


--
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 Saturday 10 June 2017 06:15:09 Edson H wrote:
> Hi Martin,
>
>
> I have seen you use "sub" for procedures or functions,  and "method" for
> object. Is it?
>
Yes.

> I think you can use only PROCEDURE keyword, for procedures and functions
> (and probably for objects), like Modula-2, do.
>
I don't like "sub" much but found nothing better up to now. I think that 
object methods deserve an own token "method" because of the implicit "self" 
parameter. Comming from a Pascal background "procedure" implies that there 
must be a "function" too but there is none in MSElang. Maybe "proc" instead 
of "sub" and "meth" instead of "method" what do you think?
"
proc test1(a: int32): flo64;
proc test2(const a: string8);
meth objty.test3(a: int32): flo64;
meth objty.test4(const a: string8);
meth ctest.test3(a: int32): flo64;
meth ctest.test4(const a: string8);
"
It has the advantage that procedure and method names are aligned. More 
experiments are needed.


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

[Edson H]

Hi Martin,


I have seen you use "sub" for procedures or functions,  and "method" for 
object. Is it?

I think you can use only PROCEDURE keyword, for procedures and functions (and 
probably for objects), like Modula-2, do.

I'm implementing functions in my compiler, and I think, it's better to use 
"sub" too, but in the other hand, I don't want to break to much the Pascal 
compatibility.



De: Martin Schreiber <mse00...@gmail.com>
Enviado: domingo, 07 de mayo de 2017 09:41 a.m.
Para: mseide-msegui-talk@lists.sourceforge.net
Asunto: Re: [MSEide-MSEgui-talk] MSElang Objects

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
mseide-msegui-talk Info Page - 
SourceForge<https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk>
lists.sourceforge.net
mseide-msegui-talk -- General list for MSEide+MSEgui About mseide-msegui-talk


--
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 22 May 2017 11:39:28 Fred van Stappen wrote:
> > Make a feature request?
>
> Hello Martin.
>
> OK, I try to do my best. --->
> http://free-pascal-general.1045716.n5.nabble.com/Size-of-program-vs-library
>-td5718200i40.html
>
> But to accept the request, the fpc team ask to -->
>
> >> Before filing a request, you can already check yourself what happens
> >> with
> >> form data if you compile a lazarus form into the library.
>
> Sorry, I am not able to compile a LCL form into library.
> I spent hours and loose lot of hair for that --> no success.
>
> So I will not do a feature request, I do not have time for this (and no
> passion).
>
I would submit a "feature request" (for me it is more a bug ;-) ) anyway so it 
will not be forgotten.
 
> PS: By the way, as you know, compiling MSEgui and fpGUI forms into library
> works like charm and no data is loosed when using  -k--gc-sections.
>
MSEgui does not use the FPC resource system.

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]

> Make a feature request?

Hello Martin.

OK, I try to do my best. ---> 
http://free-pascal-general.1045716.n5.nabble.com/Size-of-program-vs-library-td5718200i40.html

But to accept the request, the fpc team ask to -->

>> Before filing a request, you can already check yourself what happens
>> with
>> form data if you compile a lazarus form into the library.

Sorry, I am not able to compile a LCL form into library.
I spent hours and loose lot of hair for that --> no success.

So I will not do a feature request, I do not have time for this (and no 
passion).

PS: By the way, as you know, compiling MSEgui and fpGUI forms into library 
works like charm and no data is loosed when using  -k--gc-sections.

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

[Fred van Stappen]

> using Graeme's code proved that FPC has a *HUGE* weakness in the floating  
> point arena.

Aaaargh, ..., today's decent audio program/library uses quasi only float 32 bit 
resolution, all DSPs convert first the integers into float 32 before to apply 
calculs (then result is rounded/converted if integer resolution is needed).

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 Friday 19 May 2017 18:06:18 Jon Foster wrote:
[...]

> If MSElang is far enough along it would be interesting to see what it can
> do with with Graeme's ray-caster. I've dumbed it down to <300 lines and
> removed the external SDL dependency so it can be run as a raw computational
> benchmark.
>
> If you have the time to perform a translation and want to give it a whirl
> the reduced code is at https://github.com/jafcobend/fpcflop in the
> "mctest.pas"
>
I'll take a look. I hope I don't forget to CC you.

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

[Jon Foster]

On 05/07/2017 03:05 AM, Graeme Geldenhuys wrote:
> On 2017-05-07 08:20, Martin Schreiber wrote:
>> 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.
Hey Martin!

Although Graeme fails to take into account the platforms where Java is 
interpreted and its many other stupidities he does have a good test case. I 
think I stirred up to the pot on the FPC mail list as best as I can and 
using Graeme's code proved that FPC has a *HUGE* weakness in the floating 
point arena. And actually my Delphi compiler for Linux (Kylix v3) didn't do 
much better. Seems to me I remember that being the case from my Delphi 
windoze days too. Fortunately I avoid floating-point math and typically 
don't need it. And in the cases where I do... actually the only fractional 
values I have dealt with in a long time is money and I use the currency 
type which doesn't really count. :-) IEEE floating-point is hideous for that.

If MSElang is far enough along it would be interesting to see what it can 
do with with Graeme's ray-caster. I've dumbed it down to <300 lines and 
removed the external SDL dependency so it can be run as a raw computational 
benchmark.

If you have the time to perform a translation and want to give it a whirl 
the reduced code is at https://github.com/jafcobend/fpcflop in the 
"mctest.pas"

Although many on the FPC mailing list seem content to come up with excuses 
or blame Graeme for poor design it seems to me the real questions is: Why 
is x/y, when both are declared as singles, so much slower in FPC then 
it is in language X. So I'd really like to see how MSElang scores in this 
arena. I've been contemplating some game scenarios and I've been keeping my 
eye out for an improved language. Maybe I should get on board with MSElang.

Anyhow, if you take on the challenge please CC my email address below. I'm 
going to try and avoid the mail lists and newsgroups for a while. I need to 
go earn a living and these things have soaked up a ton of time. :-D

- Jon

-- 
Sent from my Debian Linux laptop
Jon Foster
JF Possibilities, Inc.
j...@jfpossibilities.com


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

[Sieghard]

Hallo Martin,

Du schriebst am Tue, 9 May 2017 07:49:01 +0200:

...
> > > >> 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? 
> Example?

Sorry, no example, not yet at least. I'm much too busy with many other
things right now, things not at all computer or programming related...
And this was just a conjecture anyway.

-- 
-- 
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
---
Mit freundlichen Grüßen, S. Schicktanz
---



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

Ha. ok, some answers there in fpc forum.

But, like always, because mom-Delphi does not use --gc-sections, fpc will not 
use it too.

Fre;D



De : Martin Schreiber <mse00...@gmail.com>
Envoyé : lundi 15 mai 2017 12:31
À : mseide-msegui-talk@lists.sourceforge.net
Objet : Re: [MSEide-MSEgui-talk] MSElang Objects

On Monday 15 May 2017 10:32:01 Fred van Stappen wrote:
> Pff, no answers (as usual).
>
>
> I begin to be lazy of fpc.
>
Make a feature request?
"
-XX should work for libraries.
"
or so.

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
mseide-msegui-talk Info Page - 
SourceForge<https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk>
lists.sourceforge.net
mseide-msegui-talk -- General list for MSEide+MSEgui About mseide-msegui-talk



--
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 15 May 2017 10:32:01 Fred van Stappen wrote:
> Pff, no answers (as usual).
>
>
> I begin to be lazy of fpc.
>
Make a feature request?
"
-XX should work for libraries.
"
or so.

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]

Pff, no answers (as usual).


I begin to be lazy of fpc.


Fre;D


De : Fred van Stappen <fi...@hotmail.com>
Envoyé : samedi 13 mai 2017 11:49
À : General list for MSEide+MSEgui
Objet : Re: [MSEide-MSEgui-talk] MSElang Objects


OK > 
http://free-pascal-general.1045716.n5.nabble.com/Size-of-program-vs-library-td5718200.html#a5728548


Thanks Martin.


Fre;D


De : Martin Schreiber <mse00...@gmail.com>
Envoyé : samedi 13 mai 2017 11:26
À : General list for MSEide+MSEgui
Objet : Re: [MSEide-MSEgui-talk] MSElang Objects

On Saturday 13 May 2017 11:14:18 Fred van Stappen wrote:
> > Compile with fpc -k--gc-sections libnude.pas
>
> Ha, so this is the trick: using  -k--gc-sections  ?
>
> Should I sent a advice in
> http://free-pascal-general.1045716.n5.nabble.com/Size-of-program-vs-library
>-td5718200.html ?
>
Yes, and the question is why FPC does not provide --gc-sections to the linker
with the -XX paramer for libraries. A bug? And you should check if the *.so
still is working with -k--gc-sections.

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
--
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 Friday 12 May 2017 20:28:54 Fred van Stappen wrote:
>
> >  accidentally not working -XX, with active smartlinking it was reduced to
> > 26072 bytes.
>
> Do you mean that you have a trick to do smartlinking working for libraries
> ?
>
No, the first time I presented the benchmark results in the meaning I had 
added -XX to the FPC parameters but actually I had not.

> > Yup, I get 29.9 KB with fpc -k--gc-sections libnude.pas
>
> So what is the conclusion, what is the trick ?
>
Compile with
"
fpc -k--gc-sections libnude.pas
"
Every FPC program or library contains system.o which is 710KB before strip.
It seems that -XX does not work with "library" so the --gc-sections linker 
command must be supplied to the linker directly.

"
fpc -XX -s prognude.pas
"
produces ppas.sh:

===
#!/bin/sh
DoExitAsm ()
{ echo "An error occurred while assembling $1"; exit 1; }
DoExitLink ()
{ echo "An error occurred while linking $1"; exit 1; }
echo Linking prognude
OFS=$IFS
IFS="
"
/usr/bin/ld -b elf32-i386 -m elf_i386--gc-sections -s -L. -o prognude 
link.res
if [ $? != 0 ]; then DoExitLink prognude; fi
IFS=$OFS
===

"
fpc -XX -s libnude.pas
"
produces ppas.sh:

===
#!/bin/sh
DoExitAsm ()
{ echo "An error occurred while assembling $1"; exit 1; }
DoExitLink ()
{ echo "An error occurred while linking $1"; exit 1; }
echo Linking liblibnude.so
OFS=$IFS
IFS="
"
/usr/bin/ld -b elf32-i386 -m elf_i386  -init FPC_SHARED_LIB_START -fini 
FPC_LIB_EXIT -soname liblibnude.so -shared -L. -o liblibnude.so link.res
if [ $? != 0 ]; then DoExitLink liblibnude.so; fi
IFS=$OFS
echo Linking liblibnude.so
OFS=$IFS
IFS="
"
/usr/bin/strip --discard-all --strip-debug liblibnude.so
if [ $? != 0 ]; then DoExitLink liblibnude.so; fi
IFS=$OFS
===
Note the missing --gc-sections.

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]

On Friday 12 May 2017 13:52:36 Fred van Stappen wrote:
> > BTW, the mergesort benchmark binary also was 177576 bytes with
> > accidentally not working -XX, with active smartlinking it was reduced to
> > 26072 bytes.
>
> Hello Martin.
>
> In a other topic, they talk about to use : -k--gc-sections.
>
Yup, I get 29.9 KB with
fpc -k--gc-sections libnude.pas
"
library libnude ;

procedure test();
begin
end;

exports
 test;
end.
"
"
objdump -h -T -t liblibnude.so

liblibnude.so: file format elf32-i386

Sections:
Idx Name  Size  VMA   LMA   File off  Algn
  0 .hash 0014  00d4  00d4  00d4  2**2
  CONTENTS, ALLOC, LOAD, READONLY, DATA
  1 .gnu.hash 0020  00e8  00e8  00e8  2**2
  CONTENTS, ALLOC, LOAD, READONLY, DATA
  2 .dynsym   0020  0108  0108  0108  2**2
  CONTENTS, ALLOC, LOAD, READONLY, DATA
  3 .dynstr   0022  0128  0128  0128  2**0
  CONTENTS, ALLOC, LOAD, READONLY, DATA
  4 .rel.dyn  1528  014c  014c  014c  2**2
  CONTENTS, ALLOC, LOAD, READONLY, DATA
  5 .text 4af0  1680  1680  1680  2**4
  CONTENTS, ALLOC, LOAD, READONLY, CODE
  6 .rodata   01b0  6170  6170  6170  2**4
  CONTENTS, ALLOC, LOAD, READONLY, DATA
  7 .eh_frame   6320  6320  6320  2**2
  CONTENTS, ALLOC, LOAD, READONLY, DATA
  8 .dynamic  00a8  7f58  7f58  6f58  2**2
  CONTENTS, ALLOC, LOAD, DATA
  9 .data 03f0  8000  8000  7000  2**4
  CONTENTS, ALLOC, LOAD, DATA
 10 .bss  1664  83f0  83f0  73f0  2**4
  ALLOC
SYMBOL TABLE:
00d4 ld  .hash   .hash
00e8 ld  .gnu.hash   .gnu.hash
0108 ld  .dynsym .dynsym
0128 ld  .dynstr .dynstr
014c ld  .rel.dyn    .rel.dyn
1680 ld  .text   .text
6170 ld  .rodata .rodata
6320 ld  .eh_frame   .eh_frame
7f58 ld  .dynamic    .dynamic
8000 ld  .data   .data
83f0 ld  .bss    .bss
1680 g F .text  0005 test


DYNAMIC SYMBOL TABLE:
1680 gDF .text  0005 test
"
Martin

--

Hello Martin.

Hum, sorry but I am a little bit loosed...

>  accidentally not working -XX, with active smartlinking it was reduced to 
> 26072 bytes.

Do you mean that you have a trick to do smartlinking working for libraries ?

> Yup, I get 29.9 KB with fpc -k--gc-sections libnude.pas

So what is the conclusion, what is the trick ?

Thanks.

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

[Edson H]

Yes. That's my compiler. It has only basic features. The idea is to integrate 
the PIC12F and PIC18F series, a simulator, a burning software and a debug 
integrated.  But it will be later.

By now it's a very optimized compiler. It's better than some other commercial 
products.



De: Martin Schreiber <mse00...@gmail.com>
Enviado: viernes, 12 de mayo de 2017 07:11 a.m.
Para: mseide-msegui-talk@lists.sourceforge.net
Asunto: Re: [MSEide-MSEgui-talk] MSElang Objects

On Friday 12 May 2017 03:44:30 Edson H wrote:
>
> I'm currently developing a Pascal Compiler

Do you refer to
https://github.com/t-edson/PicPas
[https://avatars2.githubusercontent.com/u/7736802?v=3=400]<https://github.com/t-edson/PicPas>

GitHub - t-edson/PicPas: Compilador en Pascal para 
...<https://github.com/t-edson/PicPas>
github.com
README.md PicPas 0.5.3. Pascal compiler for PIC microcontrollers. NOTE: This 
compiler is still in alpha phase and has limited functionality. PicPas is a 
simple ...


? Looks good! Does the IDE have integrated debug capabilities?
I worked many years with PIC16xxx. Programming always was done in assembler.

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
mseide-msegui-talk Info Page - 
SourceForge<https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk>
lists.sourceforge.net
mseide-msegui-talk -- General list for MSEide+MSEgui About mseide-msegui-talk


--
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 Friday 12 May 2017 13:52:36 Fred van Stappen wrote:
> > BTW, the mergesort benchmark binary also was 177576 bytes with
> > accidentally not working -XX, with active smartlinking it was reduced to
> > 26072 bytes.
>
> Hello Martin.
>
> In a other topic, they talk about to use : -k--gc-sections.
>
Yup, I get 29.9 KB with
fpc -k--gc-sections libnude.pas 
"
library libnude ;

procedure test();
begin
end;

exports
 test;
end. 
"
"
objdump -h -T -t liblibnude.so

liblibnude.so: file format elf32-i386

Sections:
Idx Name  Size  VMA   LMA   File off  Algn
  0 .hash 0014  00d4  00d4  00d4  2**2
  CONTENTS, ALLOC, LOAD, READONLY, DATA
  1 .gnu.hash 0020  00e8  00e8  00e8  2**2
  CONTENTS, ALLOC, LOAD, READONLY, DATA
  2 .dynsym   0020  0108  0108  0108  2**2
  CONTENTS, ALLOC, LOAD, READONLY, DATA
  3 .dynstr   0022  0128  0128  0128  2**0
  CONTENTS, ALLOC, LOAD, READONLY, DATA
  4 .rel.dyn  1528  014c  014c  014c  2**2
  CONTENTS, ALLOC, LOAD, READONLY, DATA
  5 .text 4af0  1680  1680  1680  2**4
  CONTENTS, ALLOC, LOAD, READONLY, CODE
  6 .rodata   01b0  6170  6170  6170  2**4
  CONTENTS, ALLOC, LOAD, READONLY, DATA
  7 .eh_frame   6320  6320  6320  2**2
  CONTENTS, ALLOC, LOAD, READONLY, DATA
  8 .dynamic  00a8  7f58  7f58  6f58  2**2
  CONTENTS, ALLOC, LOAD, DATA
  9 .data 03f0  8000  8000  7000  2**4
  CONTENTS, ALLOC, LOAD, DATA
 10 .bss  1664  83f0  83f0  73f0  2**4
  ALLOC
SYMBOL TABLE:
00d4 ld  .hash   .hash
00e8 ld  .gnu.hash   .gnu.hash
0108 ld  .dynsym .dynsym
0128 ld  .dynstr .dynstr
014c ld  .rel.dyn    .rel.dyn
1680 ld  .text   .text
6170 ld  .rodata .rodata
6320 ld  .eh_frame   .eh_frame
7f58 ld  .dynamic    .dynamic
8000 ld  .data   .data
83f0 ld  .bss    .bss
1680 g F .text  0005 test


DYNAMIC SYMBOL TABLE:
1680 gDF .text  0005 test
"
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]

> BTW, the mergesort benchmark binary also was 177576 bytes with accidentally
> not working -XX, with active smartlinking it was reduced to 26072 bytes.

Hello Martin.

In a other topic, they talk about to use : -k--gc-sections.

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 Friday 12 May 2017 06:06:41 Martin Schreiber wrote:
> On Friday 12 May 2017 00:07:09 Fred van Stappen wrote:
> > > It is logical that the libraries are bigger because the libraries
> > > contain all named code
> >
> > Huh, :
> >
> >
> > program prognude ;
> > begin
> > end.
> > => 26.9 k
> >
> > library libnude ;
> > begin
> > end.
> > => 196.3 k
>
> Have you checked with objdump what is in libnude?
>
BTW, the mergesort benchmark binary also was 177576 bytes with accidentally 
not working -XX, with active smartlinking it was reduced to 26072 bytes.

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

[Martin Schreiber]

On Friday 12 May 2017 03:44:30 Edson H wrote:
>
> I'm currently developing a Pascal Compiler

Do you refer to
https://github.com/t-edson/PicPas
? Looks good! Does the IDE have integrated debug capabilities?
I worked many years with PIC16xxx. Programming always was done in assembler.

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

[Martin Schreiber]

On Friday 12 May 2017 03:44:30 Edson H wrote:
>
> In order to avoid confusion I would suggest to use some standard or
> recommendation on names, something like "All class names must be preceded
> by the letter C"
>
In MSEgui I use "T" as prefix for class types. All other custom types have no 
prefix but "ty" postfix. There is also the {"P"} prefix for pointer 
types. "T" could be replaced by "C" which looks more correct.
>
> Sometime I think all the names of identifiers must be clear indicative of
> their type and even of the scope. Something, like PHP do with variables,
> but it would be another language.
>
I strongly am against the hungarian notation and generally use prefixes with 
caution. I think the start of a designator should contain the most important 
part in order to speed up vertical or block source scanning. For variables 
the most important part is the name IMO.
>
> I see MSELang like a new proposal for a modern language. I'm including some
> changes too, to the Pascal language in my compiler. There are people who
> thinks Pascal is perfect like it is, but I see, fortunately, you are not
> that kind of people, like I'm not.
>
Yup!
>
> I believe, I will be glad on using MSElang. I don't like you are using
> LLVM, but anyway you are doing a great work.
>
Why, what would be the alternatives?

MSElang produces an intermediate code representation
https://gitlab.com/mseide-msegui/mselang/blob/master/mselang/opglob.pas
which can be interpreted directly (mostly for testing purpose)
https://gitlab.com/mseide-msegui/mselang/blob/master/mselang/stackops.pas
or converted to LLVM bitcode
https://gitlab.com/mseide-msegui/mselang/blob/master/mselang/llvmops.pas
https://gitlab.com/mseide-msegui/mselang/blob/master/mselang/llvmbcwriter.pas

If you like to write your own optimizer and code generator you can use the 
intermediate code. The quality of LLVM produced binaries is impressive, see 
for example
https://gitlab.com/mseide-msegui/mselang/wikis/home/mselang_benchmarks
>
> Congratulations.
>
Thanks!

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

[Martin Schreiber]

On Friday 12 May 2017 00:07:09 Fred van Stappen wrote:
> > It is logical that the libraries are bigger because the libraries contain
> > all named code
>
> Huh, :
>
>
> program prognude ;
> begin
> end.
> => 26.9 k
>
> library libnude ;
> begin
> end.
> => 196.3 k

Have you checked with objdump what is in libnude?

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

[Edson H]

Hi Martin,


I'm currently developing a Pascal Compiler and I have analyzed (although not 
implemented) the best notation on managing objects and I would say, the way you 
have defined the syntax for MSELAng is exactly the way I thought it must be. 
Using clases like a dereference.


In order to avoid confusion I would suggest to use some standard or 
recommendation on names, something like "All class names must be preceded by 
the letter C"


Sometime I think all the names of identifiers must be clear indicative of their 
type and even of the scope. Something, like PHP do with variables, but it would 
be another language.


I see MSELang like a new proposal for a modern language. I'm including some 
changes too, to the Pascal language in my compiler. There are people who thinks 
Pascal is perfect like it is, but I see, fortunately, you are not that kind of 
people, like I'm not.


I believe, I will be glad on using MSElang. I don't like you are using LLVM, 
but anyway you are doing a great work.


Congratulations.




De: Martin Schreiber <mse00...@gmail.com>
Enviado: martes, 09 de mayo de 2017 01:52 p.m.
Para: mseide-msegui-talk@lists.sourceforge.net
Asunto: Re: [MSEide-MSEgui-talk] MSElang Objects

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
mseide-msegui-talk Info Page - 
SourceForge<https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk>
lists.sourceforge.net
mseide-msegui-talk -- General list for MSEide+MSEgui About mseide-msegui-talk


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

> It is logical that the libraries are bigger because the libraries contain all 
> named code


Huh, :


program prognude ;
begin
end.
=> 26.9 k

library libnude ;
begin
end.
=> 196.3 k
--
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 Thursday 11 May 2017 14:27:51 Fred van Stappen wrote:
> Hello Martin
>
> >> 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?
>
> Huh, the answers in fpc forum are nebulous:
>
> - One said it is because  parameter -fPIC is added automatic even when not
> entered by code. It seems that fpc has problems if -fPIC is not used.
>
> - Other said it is because dynamic runtime packages are not supported yet:
>   
> http://free-pascal-general.1045716.n5.nabble.com/Size-of-program-vs-library
>-td5718200.html
>
> - There was other answers too but I do not find it back.
>
You compare a smartlinked executable (-XX -CX) with the size of the 
correspondent libraries. It is logical that the libraries are bigger because 
the libraries contain all named code, the smartlinked executable contains the 
actually used code only.

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 Martin


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

Huh, the answers in fpc forum are nebulous:

- One said it is because  parameter -fPIC is added automatic even when not 
entered by code.
  It seems that fpc has problems if -fPIC is not used.

- Other said it is because dynamic runtime packages are not supported yet:
   
http://free-pascal-general.1045716.n5.nabble.com/Size-of-program-vs-library-td5718200.html

- There was other answers too but I do not find it back.

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

[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

Re: [MSEide-MSEgui-talk] MSElang Objects

[Martin Schreiber]

On Monday 08 May 2017 21:05:33 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?
>
Example?

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 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 Martin have already disagreed about this single syntax.


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

[Sieghard]

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

-- 
-- 
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
---
Mit freundlichen Grüßen, S. Schicktanz
---



--
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 18:12:19 Marcos Douglas B. Santos wrote:
> On Mon, May 8, 2017 at 12:40 PM, Martin Schreiber  
wrote:
> > "
> > "ini" and "fini" work for stack and heap.
>
> In fact, this is a good idea. But why don't use [initialization] and
> [finalization]?
> The IDE has code-completion so, is better to see a code more readable,
> don't you think?
>
MSEide has no code-completion, I don't like automatism which fiddle with my 
code and I don't like popping-up windows which disturb the flow of thoughts 
while programming. ;-)

>
> You've already answered "No, obj2 is a pointer." but what about if the
> compiler change this by itself, putting a "^" because the variable
> declaration has one?
>
> var
>  obj1: objty;  //an instance on stack, needs no create() or destroy()
>  obj2: ^objty; //on heap
> begin
>  obj1.f1:= 123;
>
>  obj2:= objty.create();
>  try
>   // I did not write the '^' but the compiler will use because the
> declaration in VAR
>   obj2.f1:= 123;
>  finally
>   obj2.destroy();
>  end;
> end;
>
It contradicts the usual Pascal and MSElang pointer notation:
"
type
 recty: record
  a: int32;
  b: int32;
 end;
 precty = ^recty;

 objty: object
  a: int32;
  b: int32;
  constructor create();
 end;
 pobjty = ^objty;

var
 rec1: recty;
 rec2: precty;
 rect3: ^recty;
 obj1:= objty;
 obj2:= pobjty;
 obj3:= ^objty;
begin
 new(rec2); //new is probably not available in MSElang
 rec3:= @rec1;
 rec1.a:= 123;
 rec2^.a:= 123;
 rec3^.b:= 456;
 obj2:= objty.create();
 obj3:= @obj1;
 obj1.a:= 123;
 obj2^.a:= 123;
// obj2.a:= 123; inconsequent!
 obj3^.b:= 456;
// obj3.b:= 456; inconsequent!
"
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 Mon, May 8, 2017 at 12:40 PM, Martin Schreiber  wrote:
> [...]
>
> No. Call it "manually":
> "
>  obj1.create();
>  obj1.destroy();
> "
> or use "ini", "fini" methods:
> "
>  objty = object
>   method theinimethod() [ini];   //called after object initialization
>   method thefinimethod() [fini]; //called before object finalization
>  end;
> "
> "ini" and "fini" work for stack and heap.

In fact, this is a good idea. But why don't use [initialization] and
[finalization]?
The IDE has code-completion so, is better to see a code more readable,
don't you think?

>> 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?
>
> The other way around, "class" exists for convenience and where one needs the
> guarantee that the instance never is allocated on stack.

I see...

>> If is possible to remove, well, this is +1 to remove class and mantain
>> just object but without "^" in calls, but we can continue using in
>> definition.
>>
> And how to access object elements if they are allocated on stack and not
> addressed via pointer?
>
> "@obj1.f1" or "obj1↓.f1" or...?

You've already answered "No, obj2 is a pointer." but what about if the
compiler change this by itself, putting a "^" because the variable
declaration has one?

var
 obj1: objty;  //an instance on stack, needs no create() or destroy()
 obj2: ^objty; //on heap
begin
 obj1.f1:= 123;

 obj2:= objty.create();
 try
  // I did not write the '^' but the compiler will use because the
declaration in VAR
  obj2.f1:= 123;
 finally
  obj2.destroy();
 end;
end;


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 Monday 08 May 2017 16:49:40 Marcos Douglas B. Santos wrote:
>
> Some questions:
>
> 1. In this case:
> obj1: objty;  //an instance on stack, needs no create() or destroy()
>
> if my object has create() or destroy() they will be executed automatically?
>
No. Call it "manually":
"
 obj1.create();
 obj1.destroy();
"
or use "ini", "fini" methods:
"
 objty = object
  method theinimethod() [ini];   //called after object initialization
  method thefinimethod() [fini]; //called before object finalization
 end;
"
"ini" and "fini" work for stack and heap.

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

The other way around, "class" exists for convenience and where one needs the 
guarantee that the instance never is allocated on stack.

> If is possible to remove, well, this is +1 to remove class and mantain
> just object but without "^" in calls, but we can continue using in
> definition.
>
And how to access object elements if they are allocated on stack and not 
addressed via pointer?

"@obj1.f1" or "obj1↓.f1" or...?

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 Mon, May 8, 2017 at 10:06 AM, Martin Schreiber  wrote:
> On Monday 08 May 2017 14:11:28 Marcos Douglas B. Santos wrote:
>> On Mon, May 8, 2017 at 2:39 AM, Martin Schreiber  wrote:
>> >> > 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.
>> >>
>> >> :)
>> >
>> > Other opinions? Should "class" be removed?
>>
>> Well, if ^TObj is the same as class and you will continue using this
>> syntax then, yes, I think class should be removed.
>> But maybe we should think more about it.
>>
> In order to clarify the difference of "object" and "class":
> "object" can be allocated on stack or on heap.
> "class" is an object which always is allocated on heap -> it always must be
> instantiated by a call of a constructor by .TheConstructor() and
> it must be destroyed by a call of a destructor by
> .TheDestructor() and it has an implicit dereference for
> element access.
> "
> type
>  objty = object
>   f1: int32;
>   f2: int32;
>   constructor create();
>   destructor destroy();
>  end;
>  pobjty = ^objty;
>
>  TObj = class(objty)
>  end;
>
> constructor objty.create();
> begin
> end;
>
> destructor objty.destroy();
> begin
> end;
>
> var
>  obj1: objty;  //an instance on stack, needs no create() or destroy()
>  obj2: ^objty; //on heap
>  obj3: pobjty;
>  obj4: TObj;   //on heap
> begin
>  obj1.f1:= 123; //no create() call necessary, no destroy() call necessary
>
>  obj2:= objty.create();
>  obj2^.f1:= 123;   //note the '^' dereference
>  obj3:= objty.create();
>  obj3^.f1:= 123;   //note the '^' dereference
>  obj4:= TObj.create();
>  obj4.f1:= 123;//no '^' dereference
>  obj2.destroy();
>  obj3.destroy();
>  obj4.destroy();
> "

Ok.

Some questions:

1. In this case:
obj1: objty;  //an instance on stack, needs no create() or destroy()

if my object has create() or destroy() they will be executed automatically?

2. In this case:
 obj2: ^objty; //on heap

Is it possible to remove the "^"?
obj2.f1:= 123;

I think this distinction exists because "class" exists, right?
If is possible to remove, well, this is +1 to remove class and mantain
just object but without "^" in calls, but we can continue using in
definition.

What do you think?


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 Monday 08 May 2017 14:11:28 Marcos Douglas B. Santos wrote:
> On Mon, May 8, 2017 at 2:39 AM, Martin Schreiber  wrote:
> >> > 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.
> >>
> >> :)
> >
> > Other opinions? Should "class" be removed?
>
> Well, if ^TObj is the same as class and you will continue using this
> syntax then, yes, I think class should be removed.
> But maybe we should think more about it.
>
In order to clarify the difference of "object" and "class":
"object" can be allocated on stack or on heap.
"class" is an object which always is allocated on heap -> it always must be 
instantiated by a call of a constructor by .TheConstructor() and 
it must be destroyed by a call of a destructor by 
.TheDestructor() and it has an implicit dereference for 
element access.
"
type
 objty = object
  f1: int32;
  f2: int32;
  constructor create();
  destructor destroy();
 end;
 pobjty = ^objty;

 TObj = class(objty)
 end;

constructor objty.create();
begin
end;

destructor objty.destroy();
begin
end;

var
 obj1: objty;  //an instance on stack, needs no create() or destroy()
 obj2: ^objty; //on heap
 obj3: pobjty;
 obj4: TObj;   //on heap
begin
 obj1.f1:= 123; //no create() call necessary, no destroy() call necessary

 obj2:= objty.create();
 obj2^.f1:= 123;   //note the '^' dereference
 obj3:= objty.create();
 obj3^.f1:= 123;   //note the '^' dereference
 obj4:= TObj.create();
 obj4.f1:= 123;//no '^' dereference
 obj2.destroy();
 obj3.destroy();
 obj4.destroy();
"

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

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

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

[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

[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

[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

[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

[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

[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

[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

[Graeme Geldenhuys]

On 2017-05-06 10:20, Martin Schreiber wrote:
> Thoughts?

What "string" and "character" types will MSElang support? Hopefully not as huge
a list as FPC and Delphi. 

hint:
   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.


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

[Martin Schreiber]

On Saturday 06 May 2017 15:13:45 Marcos Douglas B. Santos wrote:
> On Sat, May 6, 2017 at 6:20 AM, Martin Schreiber  wrote:
> > Hi,
> > I implemented objects and classes in MSElang:
> > https://gitlab.com/mseide-msegui/mselang/wikis/home/Mselang_objects
> >
> > Thoughts?
>
> In wiki home you wrote: "records, objects and classes could be unified
> in a single concept: Objects."
> But you continue using objects and classes...
>
> 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?

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 Sat, May 6, 2017 at 6:20 AM, Martin Schreiber  wrote:
> Hi,
> I implemented objects and classes in MSElang:
> https://gitlab.com/mseide-msegui/mselang/wikis/home/Mselang_objects
>
> Thoughts?

In wiki home you wrote: "records, objects and classes could be unified
in a single concept: Objects."
But you continue using objects and classes...

Use only objects and change this syntax...
o1: ^obj5ty;
...to this one
o1: obj5ty;

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 Saturday 06 May 2017 11:29:42 Fred van Stappen wrote:
>
> By the way, what can we do already with mselang ?
>
It is not ready for public use.

> Do you have some examples ?
>
Testcases for the Free Pascal dialect:
https://gitlab.com/mseide-msegui/mselang/tree/master/mselang/test

> Is it possible already to compile msegui or fpgui applications ?
>
No.

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]

De : Martin Schreiber 
Envoyé : samedi 6 mai 2017 11:20
À : mseide-msegui-talk@lists.sourceforge.net
Objet : [MSEide-MSEgui-talk] MSElang Objects

Hi,
I implemented objects and classes in MSElang:
https://gitlab.com/mseide-msegui/mselang/wikis/home/Mselang_objects


Thoughts?

--

Hello Martin.

Congrats !

By the way, what can we do already with mselang ?

Do you have some examples ?

Is it possible already to compile msegui or fpgui applications ?

Thanks.

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 25 November 2013 09:30:36 Michael Schnell wrote:
 On 11/22/2013 06:55 PM, Martin Schreiber wrote:
{$rtti on}
  property prop1: int32 read fprop1 write fprop1; //streamed
{$rtti off}

 To me this looks worse than just published (it does not make much
 sense to allow for  rtti aware private properties.

It does if one wants to develop a framework like MSEgui.

 But anyway, does the compiler need to know ? Could the properties not
 always be rtti aware and the RTL startup code search for those to be
 initialized from a resource ?

No because it hampers smartlinking.

Martin

--
Shape the Mobile Experience: Free Subscription
Software experts and developers: Be at the forefront of tech innovation.
Intel(R) Software Adrenaline delivers strategic insight and game-changing 
conversations that shape the rapidly evolving mobile landscape. Sign up now. 
http://pubads.g.doubleclick.net/gampad/clk?id=63431311iu=/4140/ostg.clktrk
___
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

[Michael Schnell]

While I think, private, protected and public are enough visibility 
complexity (omitting published and all the new fancy stuff invented by 
Embarcadero), I supposed abstract is one of the concepts that should 
be added to the description.

-Michael

--
Shape the Mobile Experience: Free Subscription
Software experts and developers: Be at the forefront of tech innovation.
Intel(R) Software Adrenaline delivers strategic insight and game-changing 
conversations that shape the rapidly evolving mobile landscape. Sign up now. 
http://pubads.g.doubleclick.net/gampad/clk?id=63431311iu=/4140/ostg.clktrk
___
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

[Michael Schnell]

On 11/22/2013 09:09 AM, Michael Schnell wrote:
   I supposed abstract is one of the concepts that should
 be added to the description.
+ reintroduce

(will non-heap objects have virtual methods ?)

BTW.:

IMO method is a more appropriate new combined  name for 
procedure/function than sub. It is commonly understood in the 
Object-world, and it's less likely that a program to be ported uses 
same as a variable name.

-Michael

--
Shape the Mobile Experience: Free Subscription
Software experts and developers: Be at the forefront of tech innovation.
Intel(R) Software Adrenaline delivers strategic insight and game-changing 
conversations that shape the rapidly evolving mobile landscape. Sign up now. 
http://pubads.g.doubleclick.net/gampad/clk?id=63431311iu=/4140/ostg.clktrk
___
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 Friday 22 November 2013 09:13:49 Michael Schnell wrote:

 (will non-heap objects have virtual methods ?)

Yes.

 BTW.:

 IMO method is a more appropriate new combined  name for
 procedure/function than sub. It is commonly understood in the
 Object-world, and it's less likely that a program to be ported uses
 same as a variable name.

Use 'method' instead of 'sub' everywhere or introduce a new keyword?

Martin

--
Shape the Mobile Experience: Free Subscription
Software experts and developers: Be at the forefront of tech innovation.
Intel(R) Software Adrenaline delivers strategic insight and game-changing 
conversations that shape the rapidly evolving mobile landscape. Sign up now. 
http://pubads.g.doubleclick.net/gampad/clk?id=63431311iu=/4140/ostg.clktrk
___
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 Friday 22 November 2013 09:09:21 Michael Schnell wrote:
 While I think, private, protected and public are enough visibility
 complexity (omitting published and all the new fancy stuff invented by
 Embarcadero), I supposed abstract is one of the concepts that should
 be added to the description.

In Delphi 'published' is used to switch on RTTI for streaming, we need another 
way to define streamed properties independent of visibility level.
'abstract' and 'reintroduce' or equivalents are planned.

Martin

--
Shape the Mobile Experience: Free Subscription
Software experts and developers: Be at the forefront of tech innovation.
Intel(R) Software Adrenaline delivers strategic insight and game-changing 
conversations that shape the rapidly evolving mobile landscape. Sign up now. 
http://pubads.g.doubleclick.net/gampad/clk?id=63431311iu=/4140/ostg.clktrk
___
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 Friday 22 November 2013 09:34:06 Michael Schnell wrote:
 On 11/22/2013 09:26 AM, Martin Schreiber wrote:
  Use 'method' instead of 'sub' everywhere or introduce a new keyword?

 Everywhere.

Doesn't 'method' imply that there is an instace pointer additional to the code 
address?

Martin

--
Shape the Mobile Experience: Free Subscription
Software experts and developers: Be at the forefront of tech innovation.
Intel(R) Software Adrenaline delivers strategic insight and game-changing 
conversations that shape the rapidly evolving mobile landscape. Sign up now. 
http://pubads.g.doubleclick.net/gampad/clk?id=63431311iu=/4140/ostg.clktrk
___
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

[Michael Schnell]

On 11/22/2013 10:54 AM, Martin Schreiber wrote:

 Doesn't 'method' imply that there is an instace pointer additional to the code
 address?

For me this would be a method of object.

(But of course this is a matter of taste.)

-Michael

--
Shape the Mobile Experience: Free Subscription
Software experts and developers: Be at the forefront of tech innovation.
Intel(R) Software Adrenaline delivers strategic insight and game-changing 
conversations that shape the rapidly evolving mobile landscape. Sign up now. 
http://pubads.g.doubleclick.net/gampad/clk?id=63431311iu=/4140/ostg.clktrk
___
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]

On Fri, Nov 22, 2013 at 5:26 AM, Martin Schreiber mse00...@gmail.com wrote:
 On Friday 22 November 2013 09:13:49 Michael Schnell wrote:

 (will non-heap objects have virtual methods ?)

 Yes.

 BTW.:

 IMO method is a more appropriate new combined  name for
 procedure/function than sub. It is commonly understood in the
 Object-world, and it's less likely that a program to be ported uses
 same as a variable name.

 Use 'method' instead of 'sub' everywhere or introduce a new keyword?

Two different worlds. Use 'method' only for Class methods of course.


'sub' was defined for function? No chance to change that?  :(

--
Marcos Douglas

--
Shape the Mobile Experience: Free Subscription
Software experts and developers: Be at the forefront of tech innovation.
Intel(R) Software Adrenaline delivers strategic insight and game-changing 
conversations that shape the rapidly evolving mobile landscape. Sign up now. 
http://pubads.g.doubleclick.net/gampad/clk?id=63431311iu=/4140/ostg.clktrk
___
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]

On Fri, Nov 22, 2013 at 5:34 AM, Michael Schnell mschn...@lumino.de wrote:
 On 11/22/2013 09:26 AM, Martin Schreiber wrote:

 Use 'method' instead of 'sub' everywhere or introduce a new keyword?

 Everywhere.

Experimente um novo navegador com tradução automática.Faça Download do
Google ChromeDispensar
Tradutor
Mas são dois mundos diferentes aqui: processuais vs OO.
IMHO não devemos unir as duas coisas.
Então, se processual é um velho mundo vamos usar uma velha palavra
chamado função ou função. Esta palavra, mesmo usando abreviatura,
falam mais do que 'sub'.
Google Tradutor para empresas:Google Toolkit de tradução para
appsTradutor de sitesGlobal Market Finder
Desativar tradução instantâneaSobre o Google
TradutorCelularPrivacidadeAjudaEnviar feedback

 I decently dislike sub. For me, a keyword should be speaking (like
 to or for) and not be an abbreviation. method is a lot shorter
 than subroutine and more speaking than sub.

I agree. But, in that context, I will be happy using 'method' or
'function' to class methods.

--
Marcos Douglas

--
Shape the Mobile Experience: Free Subscription
Software experts and developers: Be at the forefront of tech innovation.
Intel(R) Software Adrenaline delivers strategic insight and game-changing 
conversations that shape the rapidly evolving mobile landscape. Sign up now. 
http://pubads.g.doubleclick.net/gampad/clk?id=63431311iu=/4140/ostg.clktrk
___
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]

On Fri, Nov 22, 2013 at 6:54 AM, Martin Schreiber mse00...@gmail.com wrote:
 On Friday 22 November 2013 09:34:06 Michael Schnell wrote:
 On 11/22/2013 09:26 AM, Martin Schreiber wrote:
  Use 'method' instead of 'sub' everywhere or introduce a new keyword?

 Everywhere.

 Doesn't 'method' imply that there is an instace pointer additional to the code
 address?

Yes. +1

--
Marcos Douglas

--
Shape the Mobile Experience: Free Subscription
Software experts and developers: Be at the forefront of tech innovation.
Intel(R) Software Adrenaline delivers strategic insight and game-changing 
conversations that shape the rapidly evolving mobile landscape. Sign up now. 
http://pubads.g.doubleclick.net/gampad/clk?id=63431311iu=/4140/ostg.clktrk
___
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]

On Fri, Nov 22, 2013 at 5:34 AM, Michael Schnell mschn...@lumino.de wrote:
 On 11/22/2013 09:26 AM, Martin Schreiber wrote:

 Use 'method' instead of 'sub' everywhere or introduce a new keyword?

 Everywhere.

But here are two different worlds: Procedural vs. OO.
IMHO we should not combine the two things.
So if procedural is an old world we use an old word
called function or function. This word, using the same abbreviation,
speak more than 'sub'.

 I decently dislike sub. For me, a keyword should be speaking (like
 to or for) and not be an abbreviation. method is a lot shorter
 than subroutine and more speaking than sub.

I agree. But, in that context, I will be happy using 'method' or
'function' to class methods.

--
Marcos Douglas

--
Shape the Mobile Experience: Free Subscription
Software experts and developers: Be at the forefront of tech innovation.
Intel(R) Software Adrenaline delivers strategic insight and game-changing 
conversations that shape the rapidly evolving mobile landscape. Sign up now. 
http://pubads.g.doubleclick.net/gampad/clk?id=63431311iu=/4140/ostg.clktrk
___
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 Friday 22 November 2013 13:03:08 Marcos Douglas wrote:
 On Fri, Nov 22, 2013 at 5:33 AM, Martin Schreiber mse00...@gmail.com 
wrote:
  On Friday 22 November 2013 09:09:21 Michael Schnell wrote:
  While I think, private, protected and public are enough visibility
  complexity (omitting published and all the new fancy stuff invented by
  Embarcadero), I supposed abstract is one of the concepts that should
  be added to the description.
 
  In Delphi 'published' is used to switch on RTTI for streaming, we need
  another way to define streamed properties independent of visibility
  level. 'abstract' and 'reintroduce' or equivalents are planned.

 Maybe:
 tfoo = class
   func exec(); rtti;
 end;

Or with compiler switch:

tfoo = class
 private
  fprop1: int32;
  fprop2: int32;
 protected
{$rtti streaming}
  property prop1: int32 read fprop1 write fprop1;
 public
  property prop2: int32 read fprop2 write fprop2;
end;


Martin

--
Shape the Mobile Experience: Free Subscription
Software experts and developers: Be at the forefront of tech innovation.
Intel(R) Software Adrenaline delivers strategic insight and game-changing 
conversations that shape the rapidly evolving mobile landscape. Sign up now. 
http://pubads.g.doubleclick.net/gampad/clk?id=63431311iu=/4140/ostg.clktrk
___
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]

On Fri, Nov 22, 2013 at 9:26 AM, Martin Schreiber mse00...@gmail.com wrote:
 On Friday 22 November 2013 13:03:08 Marcos Douglas wrote:
 On Fri, Nov 22, 2013 at 5:33 AM, Martin Schreiber mse00...@gmail.com
 wrote:
  On Friday 22 November 2013 09:09:21 Michael Schnell wrote:
  While I think, private, protected and public are enough visibility
  complexity (omitting published and all the new fancy stuff invented by
  Embarcadero), I supposed abstract is one of the concepts that should
  be added to the description.
 
  In Delphi 'published' is used to switch on RTTI for streaming, we need
  another way to define streamed properties independent of visibility
  level. 'abstract' and 'reintroduce' or equivalents are planned.

 Maybe:
 tfoo = class
   func exec(); rtti;
 end;

 Or with compiler switch:
 
 tfoo = class
  private
   fprop1: int32;
   fprop2: int32;
  protected
 {$rtti streaming}
   property prop1: int32 read fprop1 write fprop1;
  public
   property prop2: int32 read fprop2 write fprop2;
 end;
 

But you need to close the compiler switch, right?

tfoo = class
 private
  fprop1: int32;
  fprop2: int32;
 protected
{$rtti on}
  property prop1: int32 read fprop1 write fprop1;
 public
  property prop2: int32 read fprop2 write fprop2;
{$rtti off}
end;

--
Marcos Douglas

--
Shape the Mobile Experience: Free Subscription
Software experts and developers: Be at the forefront of tech innovation.
Intel(R) Software Adrenaline delivers strategic insight and game-changing 
conversations that shape the rapidly evolving mobile landscape. Sign up now. 
http://pubads.g.doubleclick.net/gampad/clk?id=63431311iu=/4140/ostg.clktrk
___
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 Friday 22 November 2013 13:42:32 Marcos Douglas wrote:
 On Fri, Nov 22, 2013 at 9:26 AM, Martin Schreiber mse00...@gmail.com 
wrote:
  
  tfoo = class
   private
fprop1: int32;
fprop2: int32;
   protected
  {$rtti streaming}
property prop1: int32 read fprop1 write fprop1;
   public
property prop2: int32 read fprop2 write fprop2;
  end;
  

 But you need to close the compiler switch, right?
 
 tfoo = class
  private
   fprop1: int32;
   fprop2: int32;
  protected
 {$rtti on}
   property prop1: int32 read fprop1 write fprop1;
  public
   property prop2: int32 read fprop2 write fprop2;
 {$rtti off}
 end;
 

{$rtti xxx} is local to the object type definition, default at start is {$rtti 
off}. {$rtti streaming} means make rtti which can be used for streaming, set 
the streaming flag in rtti.

type
 tfoo = object //rtti is off
  private
   fprop1: int32;
   fprop2: int32;
   fprop3: int32;
  protected
   property prop1: int32 read fprop1 write fprop1; //not streamed
 {$rtti streaming}
   property prop2: int32 read fprop2 write fprop2; //streamed
  public
   property prop3: int32 read fprop3 write fprop3; //streamed
  end;

 tfoo1 = object(tfoo)   //rtti is off
  private
   fprop4: int32;
  public
   property prop4: int32 read fprop4 write fprop4; //not streamed
 end;


--
Shape the Mobile Experience: Free Subscription
Software experts and developers: Be at the forefront of tech innovation.
Intel(R) Software Adrenaline delivers strategic insight and game-changing 
conversations that shape the rapidly evolving mobile landscape. Sign up now. 
http://pubads.g.doubleclick.net/gampad/clk?id=63431311iu=/4140/ostg.clktrk
___
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 Friday 22 November 2013 13:15:07 Marcos Douglas wrote:
 On Fri, Nov 22, 2013 at 5:34 AM, Michael Schnell mschn...@lumino.de wrote:
  On 11/22/2013 09:26 AM, Martin Schreiber wrote:
  Use 'method' instead of 'sub' everywhere or introduce a new keyword?
 
  Everywhere.

 But here are two different worlds: Procedural vs. OO.
 IMHO we should not combine the two things.
 So if procedural is an old world we use an old word
 called function or function. This word, using the same abbreviation,
 speak more than 'sub'.

  I decently dislike sub. For me, a keyword should be speaking (like
  to or for) and not be an abbreviation. method is a lot shorter
  than subroutine and more speaking than sub.

 I agree. But, in that context, I will be happy using 'method' or
 'function' to class methods.

'method' for object methods with object instance pointer and 'sub' for 
ordinary subroutines is OK for me. I don't like 'method' for ordinary 
subroutines.

Martin

--
Shape the Mobile Experience: Free Subscription
Software experts and developers: Be at the forefront of tech innovation.
Intel(R) Software Adrenaline delivers strategic insight and game-changing 
conversations that shape the rapidly evolving mobile landscape. Sign up now. 
http://pubads.g.doubleclick.net/gampad/clk?id=63431311iu=/4140/ostg.clktrk
___
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 Friday 22 November 2013 13:00:22 Marcos Douglas wrote:
 On Fri, Nov 22, 2013 at 5:26 AM, Martin Schreiber mse00...@gmail.com 
wrote:
  On Friday 22 November 2013 09:13:49 Michael Schnell wrote:
  (will non-heap objects have virtual methods ?)
 
  Yes.
 
  BTW.:
 
  IMO method is a more appropriate new combined  name for
  procedure/function than sub. It is commonly understood in the
  Object-world, and it's less likely that a program to be ported uses
  same as a variable name.
 
  Use 'method' instead of 'sub' everywhere or introduce a new keyword?

 Two different worlds. Use 'method' only for Class methods of course.


 'sub' was defined for function? No chance to change that?  :(

MSElang definition will be changed until it is perfect. :-)

Martin

--
Shape the Mobile Experience: Free Subscription
Software experts and developers: Be at the forefront of tech innovation.
Intel(R) Software Adrenaline delivers strategic insight and game-changing 
conversations that shape the rapidly evolving mobile landscape. Sign up now. 
http://pubads.g.doubleclick.net/gampad/clk?id=63431311iu=/4140/ostg.clktrk
___
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]

On Fri, Nov 22, 2013 at 9:57 AM, Martin Schreiber mse00...@gmail.com wrote:
 On Friday 22 November 2013 13:42:32 Marcos Douglas wrote:
 On Fri, Nov 22, 2013 at 9:26 AM, Martin Schreiber mse00...@gmail.com
 wrote:
  
  tfoo = class
   private
fprop1: int32;
fprop2: int32;
   protected
  {$rtti streaming}
property prop1: int32 read fprop1 write fprop1;
   public
property prop2: int32 read fprop2 write fprop2;
  end;
  

 But you need to close the compiler switch, right?
 
 tfoo = class
  private
   fprop1: int32;
   fprop2: int32;
  protected
 {$rtti on}
   property prop1: int32 read fprop1 write fprop1;
  public
   property prop2: int32 read fprop2 write fprop2;
 {$rtti off}
 end;
 

 {$rtti xxx} is local to the object type definition, default at start is {$rtti
 off}. {$rtti streaming} means make rtti which can be used for streaming, set
 the streaming flag in rtti.
 
 type
  tfoo = object //rtti is off
   private
fprop1: int32;
fprop2: int32;
fprop3: int32;
   protected
property prop1: int32 read fprop1 write fprop1; //not streamed
  {$rtti streaming}
property prop2: int32 read fprop2 write fprop2; //streamed
   public
property prop3: int32 read fprop3 write fprop3; //streamed
   end;

  tfoo1 = object(tfoo)   //rtti is off
   private
fprop4: int32;
   public
property prop4: int32 read fprop4 write fprop4; //not streamed
  end;
 

But we can't do this:

type
 tfoo = object //rtti is off
  private
   fprop1: int32;
   fprop2: int32;
   fprop3: int32;
  protected
 {$rtti on}
   property prop1: int32 read fprop1 write fprop1; //streamed
 {$rtti off}
  property prop2: int32 read fprop2 write fprop2; //not streamed
  public
 {$rtti on}
  property prop3: int32 read fprop3 write fprop3; //streamed
 {$rtti off}
 end;


--
Marcos Douglas

--
Shape the Mobile Experience: Free Subscription
Software experts and developers: Be at the forefront of tech innovation.
Intel(R) Software Adrenaline delivers strategic insight and game-changing 
conversations that shape the rapidly evolving mobile landscape. Sign up now. 
http://pubads.g.doubleclick.net/gampad/clk?id=63431311iu=/4140/ostg.clktrk
___
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

[Ivanko B]

{$rtti on}
==
Why not simply a new keyword :

nortti property prop1: boiolean read boolvar1; ...;
or
rttiproperty prop1: boiolean read boolvar1; ...;

which in turn can override {$rtti on}.

It looks finer granular :) It's

--
Shape the Mobile Experience: Free Subscription
Software experts and developers: Be at the forefront of tech innovation.
Intel(R) Software Adrenaline delivers strategic insight and game-changing 
conversations that shape the rapidly evolving mobile landscape. Sign up now. 
http://pubads.g.doubleclick.net/gampad/clk?id=63431311iu=/4140/ostg.clktrk
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk