I thoroughly enjoy using object notation and the Form. object. That is why I
want a way to continue to use it to designate the data source of form objects.
I have read and re-read Keisuke’s comment, and there are aspects I do not
comprehend. I thought that the attachment between form object and data source
object is an integral relationship and I can’t see how using the form object to
obtain its underlying data source [an attribute of an object] is so bad.
And I am trying to understand the counsel:
>
> "I would focus my use of object notation to areas where classic
> code could not go, not spaces already occupied by classic code."
Not to mean any disrespect to Keisuke. He is one of the brightest 4D
programmers around.
But somehow this goes over my head. It is too philosophical to comprehend;
almost metaphysical. When I examine code that Keisuke creates, it is elegant. I
am confused as to how he would actually accomplish what we have been discussing
in an object script — would he use ‘classic 4D’ on some screen elements, and
not on others?
I do not want to resort to a mixture of ‘classic’ and object notation.
In the ‘perfect implementation’, within an object’s script:
This.value := Pretty_Format(This.value) // or something like this
“This” would give you access to the data source (being as it is basically an
attribute of an object, like Form.en_This.Company.Name).
I understand that it creates some potential for confusion in the case of
something like:
Form.en_This.Company.Name
In that this is actually an entity attribute. Perhaps the coder would somehow
start trying to extrapolate other attributes from its entity (i.e. “owner").
While one can traverse down the path (eg. Form[en_This][Company][Name] ) one
cannot traverse up the path as in:
Let $attribute = Form.en_This.Company.Name // i.e. that is what $attribute
is; pseudo-code
$attribute.owner is Form.en_This.Company // hypothetical code
( applied to Form.en_This.Company.Name giving Form.en_This.Company [in
this case, an entity] )
____
If we could at least get the DATA SOURCE of the object that is using object
notation as its data source, it would be nice:
But:
OBJECT Get data source ( *; $objName ) returns Nil for form objects (dot
notation) because it returns a pointer.
So it seems the only way to get the ’simple script’ is to do something like
hard-coding:
$temp:=Pretty_Format(Form.en_This.Company.Name) // so we don’t ’touch’
an attribute unnecessarily, triggering a save condition
If (Form.en_This.Company.Name # $temp) // if the formatting would
change the value
Form.en_This.Company.Name:= $temp
End if
And propagate it all over the place.
— Chris
> On Apr 30, 2020, at 6:23 PM, lists via 4D_Tech <[email protected]> wrote:
>
> Doug,
>
> Just for discussion sake, I'd say that a good portion of long established
> systems have 100% of their space already occupied by classic code....
>
> The use of the Form object offers so much that I am resigned to let go of
> some generic code, not happy, but willing to pay that price.
>
> Lahav
>
> -----Original Message-----
> From: 4D_Tech <[email protected]> On Behalf Of Douglas von Roeder
> via 4D_Tech
> Sent: Thursday, April 30, 2020 5:51 PM
> To: 4D iNug Technical <[email protected]>
> Cc: Douglas von Roeder <[email protected]>
> Subject: Re: Object notation replacement for use of Self in a script — v18
>
> Randy:
>
> "If there is such an issue trying to get object values to work right, what’s
> the reason to use them at all?”
> The new language is extremely powerful and I found it quite easy to pick up
> (mostly). The fact that it doesn’t give us 100% backward compatibility is not
> unexpected.
>
> "I know everyone is all excited about object notation, but it’s not
> mandatory. Why should we even consider using it if doesn’t do what we need?
> I’m sure there are some areas where it’s useful, but it sounds like there’s a
> lot where it isn’t. Am I missing something”
> “[doing everything that] we need” is a pretty high bar, wouldn’t you agree?
> For me, I’ve been using ObjectTools + constructors since the late 90’s,
> biding my time for 4D to adopt objects/object notation/OOP. At this point,
> I’ll take what I can get.
>
> While I was quite not-happy with this particular limitation (I have forms
> with hundreds of fields that use Object name that are used with Object get
> pointer), I think the last paragraph of Miyako’s posting, above, is sound
> advice - "I would focus my use of object notation to areas where classic code
> could not go, not spaces already occupied by classic code."
>
> --
> Douglas von Roeder
> 949-910-4084
>
>
> On Thu, Apr 30, 2020 at 3:03 PM Randy Kaempen via 4D_Tech <
> [email protected]> wrote:
>
>>
>>> On Apr 30, 2020, at 4:43 PM, lists via 4D_Tech
>>> <[email protected]>
>> wrote:
>>>
>>> OK, based on this design, we are back to using variables (or dynamic
>> variables) for data entry of anything that needs any kind of
>> processing done to it after an entry, having to load the values to
>> these data entry objects when loading the form, and copying the values
>> back when we want to save any user changes.
>>>
>>> OR
>>>
>>> We can use the Form.XXX notation to gain the advantage of that new
>>> nifty
>> option, but lose the generic coding ability.
>>>
>>> I'd say it's a choice, but the lack of the ability to address an
>>> object
>> from within generically definitely seems to be a glaring omission...
>>
>> If there is such an issue trying to get object values to work right,
>> what’s the reason to use them at all?
>>
>> I know everyone is all excited about object notation, but it’s not
>> mandatory. Why should we even consider using it if doesn’t do what we
>> need? I’m sure there are some areas where it’s useful, but it sounds
>> like there’s a lot where it isn’t. Am I missing something?
>>
>>
>> Randy Kaempen
>> Intellex Corporation
>>
>> **********************************************************************
>> 4D Internet Users Group (4D iNUG)
>> Archive: http://lists.4d.com/archives.html
>> Options: https://lists.4d.com/mailman/options/4d_tech
>> Unsub: mailto:[email protected]
>> **********************************************************************
> **********************************************************************
> 4D Internet Users Group (4D iNUG)
> Archive: http://lists.4d.com/archives.html
> Options: https://lists.4d.com/mailman/options/4d_tech
> Unsub: mailto:[email protected]
> **********************************************************************
> **********************************************************************
> 4D Internet Users Group (4D iNUG)
> Archive: http://lists.4d.com/archives.html
> Options: https://lists.4d.com/mailman/options/4d_tech
> Unsub: mailto:[email protected]
> **********************************************************************
**********************************************************************
4D Internet Users Group (4D iNUG)
Archive: http://lists.4d.com/archives.html
Options: https://lists.4d.com/mailman/options/4d_tech
Unsub: mailto:[email protected]
**********************************************************************
