Peter,
On Mon, Sep 16, 2019 at 1:58 AM Peter Jakobsson via 4D_Tech <
4d_tech@lists.4d.com> wrote:

> The key is the new “This” self-referencing function because it now lets
> you create an active object as a class.

It does.


> I realise OO purists may not regard it as a class,

They do not.


> Immense !
>
I agree.

For example, try this (needs v17 R3 or greater):
>
> C_OBJECT($animal;$dog;$cat;$pet)
> // 1. Define a class
> $animal:=New object("sound";"";"talk";Formula(ALERT(This.sound)))
>
To expand on the options here:
You can put that code into a method which returns the new object:

$animal:=Animal_obj

// Animal_obj

$0:=New object("sound";"";"talk";Formula(ALERT(This.sound)))


New Formula can call, and pass parameters to, a method.

// Animal_obj

C_TEXT($1;$2)

$animal_obj:=New object
$animal_obj.type:=$1
$animal_obj.name:=$2
$animal_obj.goodBoy:=null  // boolean
$animal_obj.color:=null // text

$animal_obj.talk:=New Formula(f_animal_getTalk)
$animal_obj.setGoodBoy:=New Formula(This.goodBoy:=$1))  //  what?
$animal_obj.setColor:=New Formula(This.color:=$1))

$0:=$animal_obj

// f_animal_getTalk

case of
  :(This.type="dog")

...

:(This.type="cat")

...

end case


This is a trivial use of formulas but illustrates a couple of points.
First, note the way the $1 param is handled. First, I pass in the
initialization params. You can also make these an option. In the
method Animal_obj is a text value. Later on I pass "$1" in as a boolean.
This compiles just fine. 4D sorts it out internally. So you can pass
multiple params of varying types to the formulas.

BTW, when a method returns an object you can address the properties
directly from the method. Eg:

$name:=Animal_obj("Fido";"dog").name  //  $name = "Fido"


Being able to use methods as New Formulas is very powerful. Methods run in
the context of an object formula have access to This. So cool.

Another use I am liking a lot is to put an entity reference is an object
with some formulas. Let's imagine a PERSON table.

// Person_obj (person id)

$person_obj:=New object
$person_obj.id:=$1

$person_obj.data:=ds.PERSON.get($1)  // get a reference to the entity

$person_obj.getLastEmail:=New Formula(f_person_getLastEmail)
$0:=$person_obj

//  f_person_getLastEmail

    some complicated procedure to look up the last email

$0:=LastEmail


And so on. You could write more methods to the object to retrieve common
values for Person. This can be handy when the paths to those values, in the
.data property, are related in complex ways. For myself I try to keep the
processing and look ups in these methods pretty simple and light. Heavy
queries, manipulations and calculations are best done outside this context.

 Not everyone is a fan and there are some good arguments to be made. One I
received on another channel after I posted some of these ideas:

Well my recommendation is not to use New formula ever. Even with properly
encapsulated code structured in a way that makes sense, it's still
impossible to get the context, source, or whether or not the method call
even exists in the object. It's basically just a dangerous feature at this
point just waiting to explode when your ".get()" isn't the same ".get()" as
you were expecting. 4D needs to add actual class structures for it to be
1) Easy to document and lookup the source, or see the actual function
documentation like now when we mouseover a method call.
2) Safe to use and relatively performant. Right now there would be a lot of
overhead to design an object correctly so that New formula use doesn't
spiral out of control, and even then, time consuming to maintain.


Another thing I've noticed is there is a processing overhead involved. I
see it in both compiled and interpreted uses. For anything having to do
with the UI I don't hesitate to build objects like this. The benefits are
great and the overhead unnoticeable. I tried applying it in another case
where there was no UI and a lot of processing in loops. It was slow. I'm
using the beta versions for that stuff so it may be better when it's
actually released. I say that because I suspect the overhead has to do with
whatever internal mechanism 4D uses to manage the references and I expect
it to get better as it's used more. But for now YMMV.

-- 
Kirk Brooks
San Francisco, CA
=======================

What can be said, can be said clearly,
and what you can’t say, you should shut up about

*Wittgenstein and the Computer *
**********************************************************************
4D Internet Users Group (4D iNUG)
Archive:  http://lists.4d.com/archives.html
Options: https://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**********************************************************************

Reply via email to