[MSEide-MSEgui-talk] Android & iOS

[Marcos Douglas B. Santos]

Hi,

Direct to the subject:
Can I create Apps for Android and iOS using MSEgui nowadays?

I saw Martin's comment
https://forum.lazarus.freepascal.org/index.php/topic,31996.msg205787.html?PHPSESSID=f3n3hkv8am2kh2ohvugg1v3p00#msg205787
and looks MSE isn't prepared yet.

I've seen frameworks like Castle-Engine that have a Tool which claims
to be more easy to building and packaging Apps:
https://github.com/castle-engine/castle-engine/wiki/Build-Tool

This framework looks like a piece of art, but I'm more interested to
build business applications with Forms, Grids, Lists and so on.

I believe that Ionic framework is a good choice to build mobile apps,
but if could have such apps using Object Pascal, would be nice.

Can I do that using MSE and its default widgets?

Thanks.

Best regards,
Marcos Douglas

PS. Yes, I've posted this message on Lazarus forum first, sorry.
 

  http://www.avg.com/email-signature?utm_medium=email_source=link_campaign=sig-email_content=webmail;
target="_blank">https://ipmcdn.avast.com/images/icons/icon-envelope-tick-green-avg-v1.png;
alt="" width="46" height="29" style="width: 46px; height: 29px;"
/>
Livre de vírus. http://www.avg.com/email-signature?utm_medium=email_source=link_campaign=sig-email_content=webmail;
target="_blank" style="color: #4453ea;">www.avg.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] Android & iOS

[Marcos Douglas B. Santos]

On Mon, Jul 10, 2017 at 1:34 AM, Martin Schreiber  wrote:
> The situation has not changed. I don't need it myself and there is no sponsor.
> iOS is a closed environment, Apple tries with big effort and good results to
> lock out aliens. I don't know if Android is better in this regard.

Hmm... Ok. Thanks.

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 Tue, May 9, 2017 at 10:52 AM, Martin Schreiber <mse00...@gmail.com> 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

[Marcos Douglas B. Santos]

On Tue, May 9, 2017 at 3:24 AM, Martin Schreiber <mse00...@gmail.com> wrote:
> On Monday 08 May 2017 22:44:39 Marcos Douglas B. Santos wrote:
>> On Mon, May 8, 2017 at 4:05 PM, Sieghard <s_c_...@arcor.de> 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

[Marcos Douglas B. Santos]

On Tue, May 9, 2017 at 10:00 AM, Martin Schreiber <mse00...@gmail.com> 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

[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

[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

[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

[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

[Marcos Douglas B. Santos]

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

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

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

Classes should not exists in object-oriented programming. This is a
mistake. Only objects should exists.
I'm following and participate (more or less) of a new language called
EO https://github.com/yegor256/eo that do not have classes, NULL and
other things that should not exists in OOP.

Best regards,
Marcos Douglas

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

Re: [MSEide-MSEgui-talk] MSElang Objects

[Marcos Douglas B. Santos]

On Sun, May 7, 2017 at 1:14 PM, Martin Schreiber  wrote:
>> Classes should not exists in object-oriented programming. This is a
>> mistake. Only objects should exists.
>
> In MSElang "class" = "^object" on heap. So you mean there should be no object
> heap pointers but stack allocated objects only? I probably misunderstood.

No. I'm talking just about design concepts.
I want to work with objects. If they are created in heap or not, I don't care.
But... forget that. This concept will change all in MSElang.

About your design, if "class" = "^object", why do not keep only one?

Using your syntax, I propose this:

1. TObj = object [static]  << this is like record

2. TObj = object [dynamic]  << this is like class

But a clean syntax that is much BETTER is only:

TObj = object

...and the compiler should know if that should be on heap or not.

For me, every object is a "dynamic" instance. I don't work with records.


Another questions:

1. "Methods can be virtual, interfaces are listed after the possible ancestor."
obj6ty = object(obj5ty,testintf) [virtual]
  method donothing() [virtual];
 end;

Q: to make virtual methods , I need to declare the "object" [virtual] at first?

2. "Virtual object not initialized with zeros."
obj4ty = object [virtual,nozeroinit]
 private
  ffield1: int32;
  method getfield1(): int32;
  method setfield1(const avalue: int32);
 public
  method dosomething() [virtual];
  property field1 read getfield1 write setfield1;
end;

Q: What is the point about "nozeroinit"? What the advantages?

3. Ancestor class:

 obj9ty = object(,testintf) [virtual] //no ancestor

Q: Why this ugly syntax? You are simplifying some Pascal syntax (eg:
every line should have a ";", every block has an "end", etc) but here
you are committing a mistake, IMHO.

If you allow this:

  obj4ty = object" << without ancestor

you should allow this:
  obj9ty = object(testintf) << not an acestor, but an interface

...and the compiler should know that is an interface, not a class.

>> I'm following and participate (more or less) of a new language called
>> EO https://github.com/yegor256/eo that do not have classes, NULL and
>> other things that should not exists in OOP.
>>
> That looks a little bit abstract to me. A general purpose programming language
> should be handy and not necessarily academically clean.

I pointed this project as an example about concepts that are truly
object-oriented. One of them is: no class, just objects.
I tried to propose a more Pascalish syntax, but they didn't accept all
my ideas, unfortunately.

Best regards,
Marcos Douglas

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

Re: [MSEide-MSEgui-talk] MSElang Objects

[Marcos Douglas B. Santos]

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

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

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

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

Marcos Douglas

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

Re: [MSEide-MSEgui-talk] MSElang Objects

[Marcos Douglas B. Santos]

On Sun, May 7, 2017 at 4:15 PM, Martin Schreiber <mse00...@gmail.com> wrote:
> On Sunday 07 May 2017 18:48:13 Marcos Douglas B. Santos wrote:
>> On Sun, May 7, 2017 at 1:14 PM, Martin Schreiber <mse00...@gmail.com> wrote:
>> >> Classes should not exists in object-oriented programming. This is a
>> >> mistake. Only objects should exists.
>> >
>> > In MSElang "class" = "^object" on heap. So you mean there should be no
>> > object heap pointers but stack allocated objects only? I probably
>> > misunderstood.
>>
>> No. I'm talking just about design concepts.
>> I want to work with objects. If they are created in heap or not, I don't
>> care. But... forget that. This concept will change all in MSElang.
>>
>> About your design, if "class" = "^object", why do not keep only one?
>>
>> Using your syntax, I propose this:
>>
>> 1. TObj = object [static]  << this is like record
>>
>> 2. TObj = object [dynamic]  << this is like class
>>
> Currently it can be defined in "var" section
> "
> var
>  obj1: TObj;  //on stack
>  obj2: ^TObj; //on heap
> begin
>  //obj1 does not need to be created
>  obj2:= tobj.create();
>  obj2.destroy();
> "
> or in "type" section
> "
> type
>  TObj = object
>  end;
>  PObj = ^TObj;
> var
>  obj1 = TObj;
>  obj2 = PObj;
> begin
>  //obj1 does not need to be created
>  obj2:= tobj.create();
>  obj2.destroy();
> "

Two ways to define the same thing.
Do you think this is good?

> One does not need to use "class", it can be removed. I thought that people
> comming from Free Pascal will like it. ;-)

You could be right, but I think they will like more if not exist ambiguity. :)

>> But a clean syntax that is much BETTER is only:
>>
>> TObj = object
>>
>> ...and the compiler should know if that should be on heap or not.
>>
>> For me, every object is a "dynamic" instance. I don't work with records.
>>
> I think a programmer should know what happens. See for example how slow
> LLVM-optimizer and compiler are. One reason is the excessive use
> of "advanced" C++ technics in the LLVM tools. Step through the code and check
> what happens behind the scene in almost every statement, it is crazy.

I understand.
But what about create a simple and default syntax/design to the most
developers and theirs simple applications and, at the same time,
provide some "options" like "annotations" (or some like that) to the
"hackers" that need 100% performance?

>>
>> Another questions:
>>
>> 1. "Methods can be virtual, interfaces are listed after the possible
>> ancestor." obj6ty = object(obj5ty,testintf) [virtual]
>>   method donothing() [virtual];
>>  end;
>>
>> Q: to make virtual methods , I need to declare the "object" [virtual] at
>> first?
>>
> Yes, or inherit from a virtual object. The purpose is that a virtual method
> table pointer in the data record will be reserved and initialized. The reason
> why to define it explicitely is also that IMO programmers should know what
> happens.

IMO this is too verbose.

>> 2. "Virtual object not initialized with zeros."
>> obj4ty = object [virtual,nozeroinit]
>>  private
>>   ffield1: int32;
>>   method getfield1(): int32;
>>   method setfield1(const avalue: int32);
>>  public
>>   method dosomething() [virtual];
>>   property field1 read getfield1 write setfield1;
>> end;
>>
>> Q: What is the point about "nozeroinit"? What the advantages?
>>
> Performance. There is no need to zeroing the data if it is initialized in code
> anyway.

Well, Ok. This matches I'm talking above: annotations for hackers.

>> 3. Ancestor class:
>>
>>  obj9ty = object(,testintf) [virtual] //no ancestor
>>
>> Q: Why this ugly syntax? You are simplifying some Pascal syntax (eg:
>> every line should have a ";", every block has an "end", etc) but here
>> you are committing a mistake, IMHO.
>>
>> If you allow this:
>>
>>   obj4ty = object" << without ancestor
>>
>> you should allow this:
>>   obj9ty = object(testintf) << not an acestor, but an interface
>>
>> ...and the compiler should know that is an interface, not a class.
>>
> For me code structures should always look the same. An object header is
> (ancestor,interface1,interface2...), I don't like to have an interface at the
> first position where normally the ancestor is placed.

So, is not better to do this?

1. obj4ty = object(tobject)
2. obj9ty = object(tobject, testintf)

I mean, we always need to write the ancestor.
It will always look the same.


Marcos Douglas

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
mseide-msegui-talk mailing list
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

[Marcos Douglas B. Santos]

On Mon, May 8, 2017 at 10:06 AM, Martin Schreiber <mse00...@gmail.com> 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 <mse00...@gmail.com> 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

[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

[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] fpc and memory leak.

[Marcos Douglas B. Santos]

On Tue, Jul 31, 2018 at 12:48 PM, fredvs  wrote:
> Hello.
>
> Referencing to this:
> http://lists.freepascal.org/pipermail/fpc-devel/2018-July/039369.html
>
> So, if I understand ok, after few compiling, we have to reboot the system
> because fpc has eaten lot of memory because of their memory leaks ?
>
> Huh, will MSElang have the same behaviour ?

You don't need to reboot the system.
When the process finish, the OS clean all memory that belongs it.

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] fpc and memory leak.

[Marcos Douglas B. Santos]

On Tue, Jul 31, 2018 at 2:14 PM, Martin Schreiber  wrote:
> On 07/31/2018 06:25 PM, fredvs wrote:
>> Thanks Marcos.
>>
>>> When the process finish, the OS clean all memory that belongs it.
>>
>> Sorry, I do not understand.
>> Do you mean that the OS clean all memory leak after fpc is closed?
>
> Yes.
>
>> What OS ?
>>
> Linux, FreeBSD, Windows and OSX for sure.

Thanks Martin.

@fredvs
Do not confuse with your application running.
We're talking about fpc process. It will compile your code making a
lot of memleak... then the fpc process die and the memleak is gone.
But you need paying attention if your code is producing memleaks.
However, if your application is just a console app that do the job and
dies, as FPC, then it will be the same.
Nevertheless, I always (try) clean my objects, checking with heaptrc.
It does'nt matter if is a console, Desktop, Web.

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] fpc and memory leak.

[Marcos Douglas B. Santos]

On Tue, Jul 31, 2018 at 7:42 PM, fredvs  wrote:
> @ Marcos and Douglas: thanks for your light.
>
>> However, if your application is just a console app that do the job and
>> dies, as FPC, then it will be the same.
>
> Huh, AFAIK MSE and fpGUI apps are console apps too ?

Yes, but AFAIK these apps do not have memleaks.

> Anyway, in my old time, playing with programing gives you a red card when
> your code generated a memory leak.
>
> But time has changed and maybe memory is not so rare and precious than
> before.

Nothing has changed. If your code has memleaks, something is wrong. Period.

> Like explained in fpc mailing-list, what is important now is speed and no
> matter for some memory leak if it makes code faster.

That are their thinking...
You cannot use this "approach" for apps that could stay running
"forever" like web apps on the server, DLLs, even a desktop apps that
users don't close. Memleaks, in that cases, will be a problem for
sure.

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] Useless searches all over the Internet

[Marcos Douglas B. Santos]

On Sat, Jul 7, 2018 at 8:34 PM, Graeme Geldenhuys
 wrote:
> On 07/06/18 10:03, Martin Schreiber wrote:
>> > I too make the experience that searches in
>> individual sites are mostly useless.
>
> After I discovered that Google had a 3GByte zip file of data on me (no
> videos, but 200 or so photos - the rest harvested data), I try not to
> use Google any more. DuckDuckGo gives me  the exact same information as
> Google would have, also supports "utilities" via the search engine -
> PLUS they do not track you at all (or so they claim).
>
>> In case of searching gitlab.com hosted projects the URL is
>> https://gitlab.com/explore, see attachment.
>
> Again, shows you how SH*T websites are these days. Steps I used:
>
> 1.   Go to "www.gitlab.com"
> 2.   Click on the Search link (magnifying glass) shown in the
>  navigation menu.
> 3.   Typed in "mseide" and pressed Enter.
>
> What I got was the screenshot I posted before. The above steps doesn't
> sound unreasonable to me!

Don't use gitlab.com/explore, instead just use the Search edit on the top.

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] Destiny of Martin's projects

[Marcos Douglas B. Santos]

On Tue, Feb 5, 2019 at 2:37 PM Noel Frankinet  wrote:
>
> When a C++ program is slower than its counterpart in Java, its always because 
> the C++ implementation is weak.
> Java cannot be faster than machine code and a good C++ implementation must be 
> equivalent to machine code.

And I would say the same about Object Pascal.

regards,
Marcos Douglas


___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk