OB commands, confirming a few points

classic Classic list List threaded Threaded
18 messages Options
Reply | Threaded
Open this post in threaded view
|

OB commands, confirming a few points

David Adams-4
I think that I'm missing some basics on the command set and will be
grateful to anyone that can make me just that bit less foolish going
forward. For reference, all of my root objects are from

JSON Parse ("{}")

So, that's a given.

--------------------------------
 Dot Notation
--------------------------------
Nope. I knew that from the list already. I care less than many.

--------------------------------
 Count Elements
--------------------------------
Huh. How do you count things in C_OBJECTs? Like, # of instances of an
object or whatever? I've got a case where OB GET PROPERTY NAMES works
fine...but that's a special case. Am I missing something? I checked the
JSON command suite, but it's quite small and contains nothing like a count
function.

--------------------------------
 Blind Iteration
--------------------------------
Again, huh? I don't see how you can scan an object generically and explore
its contents. I did a quick-and-dirty code dump routine that takes an
object and then leans on OB GET PROPERTY NAMES to translate everything. The
type result lets you do most of what's needed. I used recursion to explore
nested objects because I didn't feel up to taking the time to writing it
properly without recursion. The real stumbling block is when you've got a
nested array. You can stash and retrieve several array types using OB
GET/SET ARRAY:

   Boolean array
   Longint array
   Object array
   Pointer array
   Real array
   Text array

OB Get type seems to report that they're object arrays, even if you stashed
something like a longint array. OB GET ARRAY doesn't want to recast them on
the fly. (I tried putting in a longint array and pulling it out as an
object array - what 4D tells me it is - and it choked.)

Am I missing something here? 4D clearly knows the underlying data type of
arrays stashed in a C_OBJECT, but I'm unclear how to get it out. I've
bashed on the JSON Stringify command and some other bits I could find, but
I don't see even an indirect way to figure out the type. I expect trying
each of the available array types with an error handler until something
works could get it done but, well, that makes me feel like I must be
missing something obvious.

Thanks for any help.
**********************************************************************
4D Internet Users Group (4D iNUG)
FAQ:  http://lists.4d.com/faqnug.html
Archive:  http://lists.4d.com/archives.html
Options: http://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:[hidden email]
**********************************************************************
Reply | Threaded
Open this post in threaded view
|

Re: OB commands, confirming a few points

John DeSoi
David,

> On Jan 10, 2017, at 9:29 PM, David Adams <[hidden email]> wrote:

> OB Get type seems to report that they're object arrays, even if you stashed
> something like a longint array. OB GET ARRAY doesn't want to recast them on
> the fly. (I tried putting in a longint array and pulling it out as an
> object array - what 4D tells me it is - and it choked.)

I think you can cast any array type to a text array (including an object array), but not much else.

>
> Am I missing something here? 4D clearly knows the underlying data type of
> arrays stashed in a C_OBJECT, but I'm unclear how to get it out. I've
> bashed on the JSON Stringify command and some other bits I could find, but
> I don't see even an indirect way to figure out the type.

You are not missing anything. If you want a way to properly serialize and unserialize all 4D types, the only viable option is to store the type information with the value.

John DeSoi, Ph.D.
**********************************************************************
4D Internet Users Group (4D iNUG)
FAQ:  http://lists.4d.com/faqnug.html
Archive:  http://lists.4d.com/archives.html
Options: http://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:[hidden email]
**********************************************************************
Reply | Threaded
Open this post in threaded view
|

Re: OB commands, confirming a few points

David Adams-4
John,

Thanks for writing back. I've looked at your post, had another try and am
not sure if I can say this in a family-friendly way. But, eh? It seems
impossible to determine the type of an array stored in a 4D "object" using
native 4D commands. Full stop. If that's true, I have to say that I'm a bit
dumbfounded. If you need to know the internals of an object in order to use
it in all cases, that makes a whole world of sensible programming
strategies impossible to implement. I guess that you can add your own
meta-data, but it strikes me as a peculiar contraint. I'm still hoping that
I'm missing something obvious, so anyone that wants to embarrass me with
the details - please do!

As far as I can tell, 4D can store a wide range of data types in an
"object" container. As Rob pointed out, internally this is a hash table. As
far as I can find, the internals aren't described anywhere. When JPR was
offering to explain things this week, I asked specifically about this
point, but he doesn't seem to have had time to respond. In any case, the
internal storage format and the text version that we can get are different
things. So, we've got "object" values and one serialization available as a
particular bit of JSON. So, when looking at what to use and how to use it,
it makes sense to look both at the Object (Language) and JSON sections of
the language. As best as I can determine, something is missing and has been
all along. (This is what John confirms in his reply.) A summary of what I
think I'm seeing - corrections and additions welcomed:

* 4D an store several simple types as well as arrays in an "object." It can
also store objects and arrays of objects.

* The only ways to get data out of an object are

OB Get: Only for simple types, including objects.
OB GET ARRAY: Only for arrays.
* Several meta-data functions are provided, the relevant ones being:

OB GET PROPERTY NAMES
OB Get type
OB Is defined

The "type" reference here calls all arrays "Object Array", even if they're
longints or whatever

* 4D obviously has the typing information internally. This is clear from
how nicely (when that's what you want) it does coercion and handles
pointers. Likewise, that really excellent hierarchical list display
interface in the debugger clearly has access to the data types. Again, I've
got zero information on how the data is stored internally, but however it's
done, there's plenty of detail in there to support what 4D does and I'd
like to be able to do.

* You _cannot_ generate an error by trying extract an array and push it
into an array of a different type. 4D tries to coerce the data as best as
it can. I can see where this is a benefit, but it doesn't report this
situation in any way and doesn't always do helpful coercion. For example,
longint-to-object gets you an array without the stored numbers.
Object-to-text gets you a bunch of text array elements with
[object][object] instead of the JSON version of the object array element.
So, you can't figure out that you converted the array incorrectly, can't
figure out what the array should be, and may well get total garbage
*unintentionally and without any error.* That strikes me as bad.

* Okay, so let's go old-school and deal with the JSON itself directly. Why
not? Stringy and walk through the JSON tree. JSON is always a tree
structure and tree walks are a pretty bread-and-butter programming
exercise. You can't. There are no JSON traversal commands native in 4D. T

* Okay, then let's just get the JSON string version of the array by itself,
look at the format, and figure out the array type from there. Shouldn't be
too hard (perhaps, except, for pointers.) JSON syntax is pretty easy to
follow. You can't. There's no way to get just the array as a JSON string.
At least, I haven't come up with one. Has anyone?

The only option I can see for reading an object generically is to
* Stringify
* Parse the full XML tree with custom code (not happening) or NTK.
* Walk the tree.

At that point, you're either doing way to much work or not using 4D.

Okay, this is the part where people embarrass me by telling me the obvious
solution(s) I've overlooked. Please do!

If not, here are some ideas about what's needed:

* Make OB GET PROPERTY NAMES return the stored array's actual type.

* Make JSON Stringify (or similar)

* Add OB GET ARRAY AS JSON and make it work with the existing JSON
array/string commands.

* Add in normal tree-walking utilities for the JSON tree. Right now, the
JSON stuff only takes a JSON string - you can't hand in an object
reference. It would be nice to get normal node references, as an option.

The object and JSON commands are great features, but it really puzzles me
that the seem incomplete...and seemingly avoiding access to the underlying
tree structure of the JSON.
**********************************************************************
4D Internet Users Group (4D iNUG)
FAQ:  http://lists.4d.com/faqnug.html
Archive:  http://lists.4d.com/archives.html
Options: http://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:[hidden email]
**********************************************************************
Reply | Threaded
Open this post in threaded view
|

Re: OB commands, confirming a few points

David Adams-4
P.S. I just tried some snazzy magic trying to pre-coerce all arrays into
object arrays and setting them like that. If you use OB Stringify array,
you get a single quoted text block holding an 'array'. It looks like an
array as JSON, but since it's quoted it's a text value. Trying coerce that
into an object array with JSON PARSE ARRAY gets you garbage. I only tried
with longint and Boolean arrays. The longint array converted to the right
number of array elements, but with garbage. The Boolean converted to a
single value rather than all of the elements. So, this is clearly now what
the commands are intended for...The docs aren't that clear to me, it looked
like they commands might be abel to turn anything into an 'object', but
they don't.

So, what about John's idea of storing type data in the object? I guess you
would:

* Wrap the OB SET/Get array calls.

* Put each array into a nested object containing a simple type description
value and whatever array you want.

Is anyone doing this? I can see it. At least any object following these
rules would be generically readable.

Thanks for any thoughts.
**********************************************************************
4D Internet Users Group (4D iNUG)
FAQ:  http://lists.4d.com/faqnug.html
Archive:  http://lists.4d.com/archives.html
Options: http://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:[hidden email]
**********************************************************************
Reply | Threaded
Open this post in threaded view
|

Re: OB commands, confirming a few points

Wayne Stewart
David,

Peter Hay uses a nifty method of appending a type indicator onto the
property name.

So you instead of

OB SET ARRAY($MyObject_o; "My Array" ; $MyBooleanArray_ab)

OBW_SetArray ($MyObject_o; "My Array" ; ->$MyBooleanArray_ab)

Within OBW_SetArray you determine the type of the array and append _ab
to the proper name

When you use OBW_GetArray ($MyObject_o; "My Array") it looks for a
property name that matches "My Array" and then appends the the _ab
before retrieving it.

Another alternative would be something like this:

OB_SetText ($MyObject_o; "My Text"; "Hello World")

Internally you would save "My Text.Value" i.e.  "Hello World" and "My
Text.Type" i.e. Is text

For the array example above you could save:

"My Array.value", "My Array.type", "My Array.selected" (if you needed
to know the selected element.


Regards,

Wayne


Wayne Stewart
about.me/waynestewart




On 11 January 2017 at 17:13, David Adams <[hidden email]> wrote:

> P.S. I just tried some snazzy magic trying to pre-coerce all arrays into
> object arrays and setting them like that. If you use OB Stringify array,
> you get a single quoted text block holding an 'array'. It looks like an
> array as JSON, but since it's quoted it's a text value. Trying coerce that
> into an object array with JSON PARSE ARRAY gets you garbage. I only tried
> with longint and Boolean arrays. The longint array converted to the right
> number of array elements, but with garbage. The Boolean converted to a
> single value rather than all of the elements. So, this is clearly now what
> the commands are intended for...The docs aren't that clear to me, it looked
> like they commands might be abel to turn anything into an 'object', but
> they don't.
>
> So, what about John's idea of storing type data in the object? I guess you
> would:
>
> * Wrap the OB SET/Get array calls.
>
> * Put each array into a nested object containing a simple type description
> value and whatever array you want.
>
> Is anyone doing this? I can see it. At least any object following these
> rules would be generically readable.
>
> Thanks for any thoughts.
> **********************************************************************
> 4D Internet Users Group (4D iNUG)
> FAQ:  http://lists.4d.com/faqnug.html
> Archive:  http://lists.4d.com/archives.html
> Options: http://lists.4d.com/mailman/options/4d_tech
> Unsub:  mailto:[hidden email]
> **********************************************************************
**********************************************************************
4D Internet Users Group (4D iNUG)
FAQ:  http://lists.4d.com/faqnug.html
Archive:  http://lists.4d.com/archives.html
Options: http://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:[hidden email]
**********************************************************************
Reply | Threaded
Open this post in threaded view
|

Re: OB commands, confirming a few points

David Adams-4
Wayne, thanks for posting Peter's trick. It seems like a decent work-around
for this problem. Not as good as having a complete command suite, but
helpful in getting the job done.

Thanks!
**********************************************************************
4D Internet Users Group (4D iNUG)
FAQ:  http://lists.4d.com/faqnug.html
Archive:  http://lists.4d.com/archives.html
Options: http://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:[hidden email]
**********************************************************************
JPR
Reply | Threaded
Open this post in threaded view
|

Re: OB commands, confirming a few points

JPR
In reply to this post by David Adams-4
[JPR]

> From: David Adams <[hidden email]>

Hi David,

>  but he doesn't seem to have had time to respond.
OK, I apologize ;-) But in fact, I do not have time...

Before giving some explanations, I would like to point out that while Objects are widely used in DB4D and Wakanda, this concept is pretty new in 4D, and needs time to evolve and develop. Rome wasn't built in a day, and Objects are deeply transforming the very heart of 4D. So you may expect each new version to bring up new features, new possibilities, and new visions of thinking and programming your future applications.

> As far as I can tell, 4D can store a wide range of data types in an
> "object" container. As Rob pointed out, internally this is a hash table.
Exactly, this is what I explained in my previous post about associative arrays.

> As
> far as I can find, the internals aren't described anywhere.
You're right, internals aren't described, and will not be, for we need to keep room for evolution, so internal will change as they are already changing very often. As soon as we publish a description of the internal handling, Devs begin to use it and to complain at every new change...

> For reference, all of my root objects are from JSON Parse ("{}")
You can do that, but I don't see the absolute need for it.

> Dot Notation
It will come, and not in a far future. And it's very powerful.

> Count Elements
This also, but just from this simple demand, you may understand how complex it can be. Count what ? Every property ? Every sub-property ? On how many levels ? Including the arrays' sizes ? The question is : What do you want to count, and how? Obviously, today, the OB GET PROPERTY NAMES does the job, and recursivity is fun, isn't it?

> Again, huh? I don't see how you can scan an object generically and explore
> its contents.
I did it for the Component I've made for the 2016 training and the 2017 Tour (Look into CustomObjectField.4dbase). Just by getting recursively lists of properties from OB GET PROPERTY NAMES($obj; $arNames; $arTypes) You have it in the examples I've given during the Sydney's training.

> Blind Iteration
The OB GET PROPERTY NAMES($obj; $arNames; $arTypes) gives you the type of each property. The problem comes with the Arrays, for it just tell you that the type is Object Array. Every array have the same type. The 1st thing to do is to know if it's an array of Objects. For this, try this code:

OB GET ARRAY($objectPtr->;$arrProperties;$arrValues)
$sizeArray:=Size of array($arrValues)
If ($sizeArray>0)
        If ($arrValues{1}="[object Object]")  //array of Objects

        Else // Other array

        End if
End if
Now, for other arrays, you have different cases:

1- You put the array in the object, so you know what kind of array. You can use different tricks to save the type inside the array itself (like the 'zero' element) or to add to your object, an object which is the description of the object itself, or any other trick (as long as it works...)

2- It's an array coming from outer space, then you cannot 'know' the type, for it may have different types in it. You will see in a (near) future that 4D will handle the JSON Array type, in which each element may have a different type. Instead of the type of the array, you will have to check the type of each individual element.

3- It's an array created by the User. Unless you got Users able to enter directly Objects with the JSON syntax, it has to go through your code, then case 1-

> and seemingly avoiding access to the underlying tree structure of the JSON.
You can always switch back and forth between the Object and it's JSON representation, so I don't see the point...

> The object and JSON commands are great features, but it really puzzles me
> that the seem incomplete...
You are right! Because it IS incomplete! But wait a little bit, and you will see huge evolutions...

Hope this helps,

My very best,

JPR



**********************************************************************
4D Internet Users Group (4D iNUG)
FAQ:  http://lists.4d.com/faqnug.html
Archive:  http://lists.4d.com/archives.html
Options: http://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:[hidden email]
**********************************************************************
Reply | Threaded
Open this post in threaded view
|

Re: OB commands, confirming a few points

KirkBrooks
In reply to this post by David Adams-4
David,

On Tue, Jan 10, 2017 at 10:01 PM, David Adams <[hidden email]> wrote:

> It seems
> ​ ​
> impossible to determine the type of an array stored in a 4D "object" using
> native 4D commands. Full stop. If that's true, I have to say that I'm a bit
> dumbfounded. If you need to know the internals of an object in order to use
> it in all cases, that makes a whole world of sensible programming
> strategies impossible to implement. I guess that you can add your own
> meta-data, but it strikes me as a peculiar con
> ​s​
> traint.

​I think we were having a very similar discussion 2 or 3 years ago about
this very point. To me this is a manifestation of the differences in the
way javascript handles variables, because that's what a JSON is at its
core, and the way​ 4D does. In 4D-land all the data are typed, the
variables are typed and the structures are good looking. In JS-land it's
more like the Castro during the Halloween party. (That last one may be a
little obscure but you probably get the point.)

​I don't think there's a problem with the way 4D is making JSON available
within 4D so much as coming at it from a 4D perspective and expecting the
data object, the JSON, to tell us everything we need to know about itself.
I've found JSON pretty easy to grasp since I first came on it. My usage
wasn't always the most sophisticated but I got what was going on:

"​JSON is a lightweight data-interchange format ... [it is a] text format
that is completely language independent but uses conventions that are
familiar to programmers..."

Being text based means pretty much anything can be there and it's up to me
what I'm going to do with it and, therefor, how to type it.

In 4D-land we're a bit of control freaks. Even JPR gave a nod to this
referencing the deal about not wanting to publish too much detail about the
internal workings lest we start expecting those things to be immutable
instead of the results being consistent. JSON doesn't lend itself to that
level of control so well. The 4D implementation of JSON, the c-object, has
more structure than native JSON which is good when we're working in 4D but
really is a 4D thing.

​I think we expect too much from a JSON/c-object when we want it to explain
itself to such a degree. JSON is just the messenger, just a bucket of data
in text format and a c-object is that data dressed up in nicer clothes.

Personally I just don't run into issues of data typing or access using them
and some of my uses of c-objects are getting pretty involved and extended.
When I need to access something I know what level it's on or generally
where it's supposed to be so the question becomes is it there or not. But
like I said, in 4D I look at c-objects as agnostic data containers. So an
object array being able to contain multiple data types is a feature.

​But I may be thinking too small. What are some cases where ​"you need to
know the internals of an object in order to use it in all cases"?

--
Kirk Brooks
San Francisco, CA
=======================
**********************************************************************
4D Internet Users Group (4D iNUG)
FAQ:  http://lists.4d.com/faqnug.html
Archive:  http://lists.4d.com/archives.html
Options: http://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:[hidden email]
**********************************************************************
Reply | Threaded
Open this post in threaded view
|

Re: OB commands, confirming a few points

David Adams-4
In reply to this post by JPR
> On Thu, Jan 12, 2017 at 12:04 AM, JPR <[hidden email]> wrote:
> [JPR]

Thanks for confirming what I'd feared, that there are missing features and
that they've been missing for several years.

It's heartening to hear that new and powerful features are on their way.
That's great! 4D has been evolving in recent versions in some genuinely
excellent ways. I decided some years back to base no business or
programming decisions on features that do not yet exist in a stable,
shipping product. It's nice to hear about such features, but I can't plan
on them or count on them. So, for all practical purposes, they do not
exist. (And, obviously, that is the actual case.)

>  As far as I can find, the internals aren't described anywhere.
> You're right, internals aren't described, and will not be, for we need to
keep
> room for evolution, so internal will change as they are already changing
very
> often. As soon as we publish a description of the internal handling, Devs
> begin to use it and to complain at every new change...

While it may be true from time to time that developers complain about a
change based on internals, I don't think it's either that common or any
reason for major concern. Developers complain, it's our job ;-) And we
complain a LOT more about other problems. So not telling us how thing work
now because we might complain later isn't a particularly nice argument.
I've heard this argument for as long as I've been around 4D. On the one
hand, at a Summit or seminar, we may be treated to all sorts of details
about internals (sometimes with no obvious practical application), but then
at another time we're told. No! You cannot be told! It should be one or the
other: discuss certain topics or do not discuss certain topics. Using other
tools, there's no particular air of mystery surrounding how things work or
how they're implemented.

This is also one reason why I typically treat 4D as a black box and test it
out from scratch when I need to figure something out:

* The documentation is often thin, incomplete or completely absent.
Subforms and widgets? Where are they documented in detail? I never found
it. The whole two-processes on 4D Server business? Where is it documented?
I've never found it. And yet these are both considered topics of great
value and importance and promoted as such at Summits. Why no docs? (Or at
least any that I've ever found.) The answer cannot be that we shouldn't
have the information, it's that the documentation is incomplete.

* Much of what I've heard about 4D internals down the years has not been
true. Well, it may well have been 100% true from a certain point of view,
but it wasn't true in a way that could be measured externally in a real
app, so it wasn't useful.

So why would I want to hear anything about internals? Well, because it is
entirely helpful to hear a good technical discussion at the level of
patterns, algorithms, or even implementation. You to give you a tiny trick
to hang onto (and then suffer from when it breaks), but to give you a
better mental map of the system. It makes it a lot easier to build solid
designs on top of a clear understanding, leaving out little tricks. LR and
Aparajita, for example, are both masters of this sort of explanation. The
sort of discussions that make you feel smarter after you were in the room
;-) When I have to select amongst tools, commercial APIs, and frameworks,
just about the first thing I do is to try the tool out, work with the docs,
and write to tech support with a question. My choice of tools depends more
on the docs and how my question is dealt with than the features. (In many
situations, multiple tools offer enough features.)

It's quite time-consuming and at times exhausting to have to research 4D's
behavior on my own. More comprehensive and reliable documentation of
various sorts would make 4D a whole lot more appealing. As an example,
subforms sound just fantastic...but I couldn't find any docs, didn't get
them to work as I could find described and so I gave up. It's just too much
work. And without docs, I have really got no idea how future versions might
change things. Components, for example, have had radical changes made
between versions so I only try them again every couple of big releases.
Help me out here people, are there any good docs on subforms? I know a few
of you use them, but I've kind of taken them to be a Miyako-only feature
;-) But he's smarter than most everyone else, so that doesn't make me
qualified to use them.

> > Count Elements
> This also, but just from this simple demand, you may understand how
complex it
> can be. Count what ? Every property ? Every sub-property ? On how many
levels
> ? Including the arrays' sizes ? The question is : What do you want to
count,
> and how? Obviously, today, the OB GET PROPERTY NAMES does the job

Your answer points to the underlying problem: The JSON isn't being exposed
as a tree. I don't expect the object commands to do that, but the JSON
commands should. I mean, it's like having to deal with an XML DOM without
tree navigation. If you've got tree nodes, then it's entirely clear what to
count. (Or at least you can know how to traverse the nodes and count as you
like.)

> recursivity is fun, isn't it?
<pointless_side_rant>I'm not a fan of recursion. It's just a
quick-and-dirty way of getting a memory-inefficient processing stack. Years
ago I didn't get it, then I did, saw the appeal, and quickly realized it's
kind of a lazy approach and broadly over-recommended. I mean, every
you're-new-to-programming-let's-do-a-factorial example in history seems to
use recursion. Why? It kind of blows your mind the first time you 'get it'
and I think that's pretty seductive for many of us, at least for a bit. But
it was the quick way of doing it in this case and there's no real chance of
a runaway situation.</pointless_side_rant>

> I did it for the Component I've made for the 2016 training and the 2017
Tour
> (Look into CustomObjectField.4dbase). Just by getting recursively lists of
> properties from OB GET PROPERTY NAMES($obj; $arNames; $arTypes) You have
it in
> the examples I've given during the Sydney's training.

Hey! Thanks for the reminder. I just dug it up and the demo looks really
great. I love that you've taken the same data structure and offered so many
views onto it. Beautiful. The underlying code is pretty dense, but it seems
that what you're doing is what you describe in your post:

* Cast any array with elements as text and see if the first element is
[object Object]. If so, deal with it as an array of objects.

* For everything else, treat it as text - no matter what it's original type.

Warning: You're depending on the coercion of object arrays to text arrays
turning up as [object Object]. I think that this is an undocumented
behavior, so 4D may change it in a future version. Then again, you can go
and complain to those guys directly ;-)

Memo to self: Never count on this behavior if you plan to store the string
[object Object] in a text array element.

> You are right! Because it IS incomplete! But wait a little bit, and you
will
> see huge evolutions...

I'll be very pleased when that day arrives. As people may have noticed from
my crazed posts on CALL FORM and CALL WORKER, I can be a pretty big fan of
beautifully done features.

> Hope this helps,
> My very best,
> JPR

Thanks for taking the time to answer when you are understandably busy. It's
always great to hear from people that work at or with the 4D companies
directly.
**********************************************************************
4D Internet Users Group (4D iNUG)
FAQ:  http://lists.4d.com/faqnug.html
Archive:  http://lists.4d.com/archives.html
Options: http://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:[hidden email]
**********************************************************************
Reply | Threaded
Open this post in threaded view
|

Re: OB commands, confirming a few points

David Adams-4
In reply to this post by KirkBrooks
Hey Kirk, thanks for the post. I'm absolutely _not_ coming to JSON with a
4D perspective. Quite the opposite. JSON is great for many, many things.
I'm just used to have tons of options for parsing it and converting it. You
get that in <insert name of basically any language>, usually with multiple
options. It's just weird that 4D doesn't have a normal JSON suite.

To be clear, I don't think much is missing in this respect over on the
C_OBJECT side of the barn, it's the JSON suite that's incomplete. JSON
should always be manageable as a tree of nodes with names, values, and data
types. It's fundamental and universal...with one exception...
**********************************************************************
4D Internet Users Group (4D iNUG)
FAQ:  http://lists.4d.com/faqnug.html
Archive:  http://lists.4d.com/archives.html
Options: http://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:[hidden email]
**********************************************************************
JPR
Reply | Threaded
Open this post in threaded view
|

Re: OB commands, confirming a few points

JPR
In reply to this post by David Adams-4
[JPR]

> Thanks for confirming what I'd feared, that there are missing features and
> that they've been missing for several years.

I fully agree with you, David!  And this problem is recurrent!

Since I know 4D (1984), it has always been missing features,and I'm still waiting for missing features for 32 years!

For instance, CONVERT PICTURE TO 3D, Find by Smell, 3D Print Object, and the one I'm expecting since 4DFr V0.8ß:

$solution := SOLVE PROBLEM ($myProblem; $ZwayUwant; *)

(Sorry, I couldn't resist ;-)))))


> On 12 Jan 2017, at 02:08, [hidden email] wrote:
>
> Date: Thu, 12 Jan 2017 07:59:21 +1100
> From: David Adams <[hidden email]>
> To: 4D iNug Technical <[hidden email]>
> Subject: Re: OB commands, confirming a few points
> Message-ID:
> <CAPXPcQt+FEbRCuJR5USbNbJYdJddJEOiKP5QVkMEUEgDMx_=[hidden email]>
> Content-Type: text/plain; charset=UTF-8
>
>> On Thu, Jan 12, 2017 at 12:04 AM, JPR <[hidden email]> wrote:
>> [JPR]
>
> Thanks for confirming what I'd feared, that there are missing features and
> that they've been missing for several years.

**********************************************************************
4D Internet Users Group (4D iNUG)
FAQ:  http://lists.4d.com/faqnug.html
Archive:  http://lists.4d.com/archives.html
Options: http://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:[hidden email]
**********************************************************************
Reply | Threaded
Open this post in threaded view
|

RE: OB commands, confirming a few points

Dennis, Neil-2
> $solution := SOLVE PROBLEM ($myProblem; $ZwayUwant; *)

I seconded this feature request :)

Neil




--



Privacy Disclaimer: This message contains confidential information and is intended only for the named addressee. If you are not the named addressee you should not disseminate, distribute or copy this email. Please delete this email from your system and notify the sender immediately by replying to this email.  If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.

The Alternative Investments division of UMB Fund Services provides a full range of services to hedge funds, funds of funds and private equity funds.  Any tax advice in this communication is not intended to be used, and cannot be used, by a client or any other person or entity for the purpose of (a) avoiding penalties that may be imposed on any taxpayer or (b) promoting, marketing, or recommending to another party any matter addressed herein.
**********************************************************************
4D Internet Users Group (4D iNUG)
FAQ:  http://lists.4d.com/faqnug.html
Archive:  http://lists.4d.com/archives.html
Options: http://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:[hidden email]
**********************************************************************
Reply | Threaded
Open this post in threaded view
|

Re: OB commands, confirming a few points

Robert McKeever
In reply to this post by JPR
And, how about the obvious:  3D Print Money ($Currency; $amount)

> On Jan 11, 2017, at 10:26 PM, JPR <[hidden email]> wrote:
>
> [JPR]
>
>> Thanks for confirming what I'd feared, that there are missing features and
>> that they've been missing for several years.
>
> I fully agree with you, David!  And this problem is recurrent!
>
> Since I know 4D (1984), it has always been missing features,and I'm still waiting for missing features for 32 years!
>
> For instance, CONVERT PICTURE TO 3D, Find by Smell, 3D Print Object, and the one I'm expecting since 4DFr V0.8ß:
>
> $solution := SOLVE PROBLEM ($myProblem; $ZwayUwant; *)
>
> (Sorry, I couldn't resist ;-)))))
>
>
>> On 12 Jan 2017, at 02:08, [hidden email] wrote:
>>
>> Date: Thu, 12 Jan 2017 07:59:21 +1100
>> From: David Adams <[hidden email]>
>> To: 4D iNug Technical <[hidden email]>
>> Subject: Re: OB commands, confirming a few points
>> Message-ID:
>> <CAPXPcQt+FEbRCuJR5USbNbJYdJddJEOiKP5QVkMEUEgDMx_=[hidden email]>
>> Content-Type: text/plain; charset=UTF-8
>>
>>> On Thu, Jan 12, 2017 at 12:04 AM, JPR <[hidden email]> wrote:
>>> [JPR]
>>
>> Thanks for confirming what I'd feared, that there are missing features and
>> that they've been missing for several years.
>
> **********************************************************************
> 4D Internet Users Group (4D iNUG)
> FAQ:  http://lists.4d.com/faqnug.html
> Archive:  http://lists.4d.com/archives.html
> Options: http://lists.4d.com/mailman/options/4d_tech
> Unsub:  mailto:[hidden email]
> **********************************************************************

_________________________________________
Bob McKeever                      http://www.mswl.com <http://www.mswl.com/>
McKeever's Software Wizardry
Port Coquitlam, B.C.
[hidden email]




**********************************************************************
4D Internet Users Group (4D iNUG)
FAQ:  http://lists.4d.com/faqnug.html
Archive:  http://lists.4d.com/archives.html
Options: http://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:[hidden email]
**********************************************************************
Reply | Threaded
Open this post in threaded view
|

Re: OB commands, confirming a few points

Tim Nevels-2
In reply to this post by David Adams-4
On Jan 12, 2017, at 2:00 PM, Robert McKeever wrote:

> And, how about the obvious:  3D Print Money ($Currency; $amount)

Robert, that is already available via the replicator technology that is in use in the Secret Space Program. Once “full disclosure” is made, which should be this year or next year, the replicator technology will be made available to all the people of earth. Of course once you can replicate a gold coin or a $100 bill the value of money is going to be, at best, questionable. :)

I just love stories about aliens and space travel. Don’t you? :)

Mt Shasta Secret Space Program Conference - Corey Goode Presentation
https://www.youtube.com/watch?v=vXhulEQib5U

Tim

********************************************
Tim Nevels
Innovative Solutions
785-749-3444
[hidden email]
********************************************

**********************************************************************
4D Internet Users Group (4D iNUG)
FAQ:  http://lists.4d.com/faqnug.html
Archive:  http://lists.4d.com/archives.html
Options: http://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:[hidden email]
**********************************************************************
JPR
Reply | Threaded
Open this post in threaded view
|

Re: OB commands, confirming a few points

JPR
In reply to this post by David Adams-4
[JPR]

Hi Bob,

> And, how about the obvious:  3D Print Money ($Currency; $amount)
You don't have it ? I'm surprised, I use it for a while now... Let me check...

Ah, I understand, it has been an undocumented command, working only until 2016, Dec 31st.You should have used it before...

Anyways, it has been replaced by a new command, much more powerful. In V16R??, have a look in the topic "Spock resources", in 4D_V16_Language.pdf, (the computer date must be set to Friday, 13th (like today)), and you will find it:

C_OBJECT($parameter,$result)
GET HELLUVA ($what;  $parameter ;$result; {*})

where:
$what   Longint -> One of the following constant:
        • Banknotes (In $parameter, pass the properties:
                - "Currency", (3-letter international code, like "$US" or "EUR")
                - "Face_value" (Longint) (Note: Results are better if multiple of 10 like 50, 100, 500 are used, instead of 12, 33, or 666)
                - "Number" (Longint)

        • SisterSoul (In $parameter, pass the properties:
                - "Sex", (Decimal boolean value, between 0,00 and True)
                - "Height" (Object with 3 Longint properties "Max", "Min", "Preferred")
                - "Weight" (Object with 3 Longint properties "Max", "Min", "Preferred")
                - "IQ" (Object with 3 Longint properties "Max", "Min", "LessThanMe")

        • Health (In $parameter, pass the properties:
                - "Level", (Real between 0 and 1, with 0 = Very good, and 1 = Much more than perfect)

        • Luck level (In $parameter, pass the properties:
                - "Level", (Real between 0 and 1, with 0 = Very good, and 1 = Much more than perfect)

$parameter Object (see above)
$result Object (Use OB GET PROPERTY NAMES to find out the different properties filled by the command)
{*} No use, but a 4D Command becomes a real 4D Commande only after getting a * parameter, otherwise it looks unfinished...

Nice command, I think...

My very best,

JPR

> On 12 Jan 2017, at 21:00, [hidden email] wrote:
>
> Date: Thu, 12 Jan 2017 08:51:06 -0800
> From: Robert McKeever <[hidden email]>
> To: 4D iNug Technical <[hidden email]>
> Subject: Re: OB commands, confirming a few points
> Message-ID: <[hidden email]>
> Content-Type: text/plain; charset=utf-8
>
> And, how about the obvious:  3D Print Money ($Currency; $amount)
>
>> On Jan 11, 2017, at 10:26 PM, JPR <[hidden email]> wrote:
>>
>> [JPR]
>>
>>> Thanks for confirming what I'd feared, that there are missing features and
>>> that they've been missing for several years.

**********************************************************************
4D Internet Users Group (4D iNUG)
FAQ:  http://lists.4d.com/faqnug.html
Archive:  http://lists.4d.com/archives.html
Options: http://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:[hidden email]
**********************************************************************
Reply | Threaded
Open this post in threaded view
|

Re: OB commands, confirming a few points

David Adams-4
Right, so when will 4D remove the 1 billion limit on the GET HELLUVA
command? And what about support for exchange rates? Seriously, what a joke!
Other languages already have GET HELLUVA with a limit over a billion and
support for the full range of major currencies.

Sincerely,

Angry old man shaking fist at cloud...

https://www.flickr.com/photos/13199528@N08/4593531893
**********************************************************************
4D Internet Users Group (4D iNUG)
FAQ:  http://lists.4d.com/faqnug.html
Archive:  http://lists.4d.com/archives.html
Options: http://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:[hidden email]
**********************************************************************
Reply | Threaded
Open this post in threaded view
|

Re: OB commands, confirming a few points

Arnaud de Montard
In reply to this post by Dennis, Neil-2

> Le 12 janv. 2017 à 16:48, Dennis, Neil <[hidden email]> a écrit :
>
>> $solution := SOLVE PROBLEM ($myProblem; $ZwayUwant; *)
>
> I seconded this feature request :)

The Office of Complaint Filings is here:
<http://forums.4d.fr/Forum/FR/1075213/0/0>
don't be shy it's friday

--
Arnaud de Montard


**********************************************************************
4D Internet Users Group (4D iNUG)
FAQ:  http://lists.4d.com/faqnug.html
Archive:  http://lists.4d.com/archives.html
Options: http://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:[hidden email]
**********************************************************************
Reply | Threaded
Open this post in threaded view
|

Re: OB commands, confirming a few points

David Adams-4
For anyone still following along with this (and for the archives), I joined
Arnaud on the forums and got in trouble ;-) I also made a few feature
requests:

New command: JSON Stringify stored array
http://forums.4d.fr/Post//18931320/1/

OB Get Array 4D type
http://forums.4d.fr/Post//18931295/1/

OB GET PROPERTY NAMES enhancement
http://forums.4d.fr/Post//18931215/1/

I'm also cross-posting (mea culpa) so code for anyone interested in the way
4D coerces arrays of different types out of a C_OBJECT area. It's really
dumb code. This is from V16.0 in a brand new database. The results appear
the same interpreted and compiled It lets you see what you get for the
supported types apart from pointers. I haven't tried pointers via objects
yet so I left them out. If anyone feels like updating the code, I'd be
happy to see the results. Sorry, I don't know the names of the commands in
French, this is just code in English.

ARRAY BOOLEAN(boolean_array_in;0)
APPEND TO ARRAY(boolean_array_in;True)
APPEND TO ARRAY(boolean_array_in;False)
APPEND TO ARRAY(boolean_array_in;True)

ARRAY REAL(real_array_in;0)
APPEND TO ARRAY(real_array_in;1.1)
APPEND TO ARRAY(real_array_in;2.2)
APPEND TO ARRAY(real_array_in;3.3)

ARRAY TEXT(text_array_in;0)
APPEND TO ARRAY(text_array_in;"monday")
APPEND TO ARRAY(text_array_in;"tuesday")
APPEND TO ARRAY(text_array_in;"wednesday")

ARRAY OBJECT(object_array_in;0)
C_OBJECT($empty_object)

C_OBJECT($simple_object)
$simple_object:=JSON Parse("{}")

C_OBJECT($object_with_a_few_elements)
$object_with_a_few_elements:=JSON Parse("{}")
OB SET($object_with_a_few_elements;"Number";Pi)
OB SET($object_with_a_few_elements;"Text";"Hello world!")
OB SET($object_with_a_few_elements;"Boolean";True)

APPEND TO ARRAY(object_array_in;$empty_object)
APPEND TO ARRAY(object_array_in;$simple_object)
APPEND TO ARRAY(object_array_in;$object_with_a_few_elements)

C_OBJECT(object)
object:=JSON Parse("{}")
OB SET ARRAY(object;"boolean_array_in";boolean_array_in)
OB SET ARRAY(object;"real_array_in";real_array_in)
OB SET ARRAY(object;"text_array_in";text_array_in)
OB SET ARRAY(object;"object_array_in";object_array_in)

C_TEXT($cr)
$cr:=Char(Carriage return)

C_TEXT($dump_text)
$dump_text:=""
$dump_text:=$dump_text+"JSON Stringify of complete object."
$dump_text:=$dump_text+$cr

C_TEXT($json)
$dump_text:=$dump_text+JSON Stringify(object;*)+$cr+$cr
$dump_text:=$dump_text+$cr

$dump_text:=$dump_text+"----------------------------------------------------------"+$cr
$dump_text:=$dump_text+"Pull each type out into a Boolean array"+$cr
$dump_text:=$dump_text+"----------------------------------------------------------"+$cr

ARRAY BOOLEAN(boolean_array_out;0)
ARRAY REAL(real_array_out;0)
ARRAY TEXT(text_array_out;0)
ARRAY OBJECT(object_array_out;0)

OB GET ARRAY(object;"boolean_array_in";boolean_array_out)
OB GET ARRAY(object;"boolean_array_in";real_array_out)
OB GET ARRAY(object;"boolean_array_in";text_array_out)
OB GET ARRAY(object;"boolean_array_in";object_array_out)

$dump_text:=$dump_text+"Source array boolean_array_in"+$cr
$dump_text:=$dump_text+JSON Stringify array(boolean_array_in)+$cr+$cr

$dump_text:=$dump_text+"Output array boolean_array_out"+$cr
$dump_text:=$dump_text+JSON Stringify array(boolean_array_out)+$cr+$cr

$dump_text:=$dump_text+"Output array real_array_out"+$cr
$dump_text:=$dump_text+JSON Stringify array(real_array_out)+$cr+$cr

$dump_text:=$dump_text+"Output array text_array_out"+$cr
$dump_text:=$dump_text+JSON Stringify array(text_array_out)+$cr+$cr

$dump_text:=$dump_text+"Output array object_array_out"+$cr
$dump_text:=$dump_text+JSON Stringify array(object_array_out)+$cr+$cr

$dump_text:=$dump_text+"----------------------------------------------------------"+$cr
$dump_text:=$dump_text+"Pull each type out into a Real array"+$cr
$dump_text:=$dump_text+"----------------------------------------------------------"+$cr

ARRAY BOOLEAN(boolean_array_out;0)
ARRAY REAL(real_array_out;0)
ARRAY TEXT(text_array_out;0)
ARRAY OBJECT(object_array_out;0)

OB GET ARRAY(object;"real_array_in";boolean_array_out)
OB GET ARRAY(object;"real_array_in";real_array_out)
OB GET ARRAY(object;"real_array_in";text_array_out)
OB GET ARRAY(object;"real_array_in";object_array_out)

$dump_text:=$dump_text+"Source array real_array_in"+$cr
$dump_text:=$dump_text+JSON Stringify array(real_array_in)+$cr+$cr

$dump_text:=$dump_text+"Output array boolean_array_out"+$cr
$dump_text:=$dump_text+JSON Stringify array(boolean_array_out)+$cr+$cr

$dump_text:=$dump_text+"Output array real_array_out"+$cr
$dump_text:=$dump_text+JSON Stringify array(real_array_out)+$cr+$cr

$dump_text:=$dump_text+"Output array text_array_out"+$cr
$dump_text:=$dump_text+JSON Stringify array(text_array_out)+$cr+$cr

$dump_text:=$dump_text+"Output array object_array_out"+$cr
$dump_text:=$dump_text+JSON Stringify array(object_array_out)+$cr+$cr

$dump_text:=$dump_text+"----------------------------------------------------------"+$cr
$dump_text:=$dump_text+"Pull each type out into a Text array"+$cr
$dump_text:=$dump_text+"----------------------------------------------------------"+$cr

ARRAY BOOLEAN(boolean_array_out;0)
ARRAY REAL(real_array_out;0)
ARRAY TEXT(text_array_out;0)
ARRAY OBJECT(object_array_out;0)

OB GET ARRAY(object;"text_array_in";boolean_array_out)
OB GET ARRAY(object;"text_array_in";real_array_out)
OB GET ARRAY(object;"text_array_in";text_array_out)
OB GET ARRAY(object;"text_array_in";object_array_out)

$dump_text:=$dump_text+"Source array text_array_in"+$cr
$dump_text:=$dump_text+JSON Stringify array(text_array_in)+$cr+$cr

$dump_text:=$dump_text+"Output array boolean_array_out"+$cr
$dump_text:=$dump_text+JSON Stringify array(boolean_array_out)+$cr+$cr

$dump_text:=$dump_text+"Output array real_array_out"+$cr
$dump_text:=$dump_text+JSON Stringify array(real_array_out)+$cr+$cr

$dump_text:=$dump_text+"Output array text_array_out"+$cr
$dump_text:=$dump_text+JSON Stringify array(text_array_out)+$cr+$cr

$dump_text:=$dump_text+"Output array object_array_out"+$cr
$dump_text:=$dump_text+JSON Stringify array(object_array_out)+$cr+$cr

$dump_text:=$dump_text+"----------------------------------------------------------"+$cr
$dump_text:=$dump_text+"Pull each type out into a Object array"+$cr
$dump_text:=$dump_text+"----------------------------------------------------------"+$cr

ARRAY BOOLEAN(boolean_array_out;0)
ARRAY REAL(real_array_out;0)
ARRAY TEXT(text_array_out;0)
ARRAY OBJECT(object_array_out;0)

OB GET ARRAY(object;"object_array_in";boolean_array_out)
OB GET ARRAY(object;"object_array_in";real_array_out)
OB GET ARRAY(object;"object_array_in";text_array_out)
OB GET ARRAY(object;"object_array_in";object_array_out)

$dump_text:=$dump_text+"Source array object_array_in"+$cr
$dump_text:=$dump_text+JSON Stringify array(object_array_in)+$cr+$cr

$dump_text:=$dump_text+"Output array boolean_array_out"+$cr
$dump_text:=$dump_text+JSON Stringify array(boolean_array_out)+$cr+$cr

$dump_text:=$dump_text+"Output array real_array_out"+$cr
$dump_text:=$dump_text+JSON Stringify array(real_array_out)+$cr+$cr

$dump_text:=$dump_text+"Output array text_array_out"+$cr
$dump_text:=$dump_text+JSON Stringify array(text_array_out)+$cr+$cr

$dump_text:=$dump_text+"Output array object_array_out"+$cr
$dump_text:=$dump_text+JSON Stringify array(object_array_out)+$cr+$cr

SET TEXT TO PASTEBOARD($dump_text)
**********************************************************************
4D Internet Users Group (4D iNUG)
FAQ:  http://lists.4d.com/faqnug.html
Archive:  http://lists.4d.com/archives.html
Options: http://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:[hidden email]
**********************************************************************