Re: A use case for C_VARIANT
On Sun, Nov 3, 2019 at 2:21 PM Keisuke Miyako via 4D_Tech < 4d_tech@lists.4d.com> wrote: > finally, it would be more appropriate to discuss v18 features on the beta > forums: > > https://forums.4d.com/List_Message/JP:0/0/2/1/1/1/14234613/0/0/1/-1/0/0/0/0/0/0 > You are entirely correct. My bad. -- 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 **
Re: A use case for C_VARIANT
for reference:
For each" expects the iterator and elements to all be of the same time
https://doc.4d.com/4Dv17/4D/17.3/For-eachEnd-for-each.300-4621439.en.html
but it is possible to use "This.value" in listboxes
https://doc.4d.com/4Dv17/4D/17.3/Managing-List-Box-Objects.300-4621083.en.html
and $1.value in collection methods
https://doc.4d.com/4Dv17/4D/17.3/collectionmap.305-4621807.en.html
as well as $col[$i] in a "For" loop
https://doc.4d.com/4Dv17/4D/17.3/Value-type.301-4620763.en.html
so there are already ways to iterate mixed collections in v17, without the
variant type.
---
the use of variant type (or object properties in general as its substitute)
does allow for generic code,
but an over-use of it may lead to runtime errors and a hit on performance (we
have strong types for a reason).
---
finally, it would be more appropriate to discuss v18 features on the beta
forums:
https://forums.4d.com/List_Message/JP:0/0/2/1/1/1/14234613/0/0/1/-1/0/0/0/0/0/0
> 2019/11/03 3:40、Kirk Brooks via 4D_Tech <4d_tech@lists.4d.com>のメール:
>
> $tuple_col:=New collection("a";"b";"c";null;null;null;"z")
>
> I want to iterate through the collection and concatenate the values into a
> string.
>
> $str:=""
> For each ($element;$tpl_col)
>
> If ($element#Null)
>
> $str:=$str+$element
>
> End if
>
> $str:=$str+$delim
>
> End for each
>
> If this code is interpreted and not typed things are fine. As soon as I
> declare $element as TEXT it throws an error when I hit a Null. If I declare
> it as an object it throws an error when it hits a text. But if I declare
> $element as C_VARIANT it's all good.
**
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
**
Re: A use case for C_VARIANT
Good explanation, Kirk, especially because it is so simple.
I had not been able to ‘get into’ v18 yet—just a cursory glance at the
documentation—What’s new etc. This is a very exciting feature.
It will definitely help when processing collections, etc.
— Chris
> On Nov 2, 2019, at 12:40 PM, Kirk Brooks via 4D_Tech <4d_tech@lists.4d.com>
> wrote:
>
> The v18 beta introduces a new variable type: variant. Not surprisingly
> there is already discussion about what it could possibly be useful for and
> why it doesn't have more capabilities. We are who we are.
>
> I have come across a clear case where it's a perfect solution.
>
> Consider a collection of text and null values. Like so:
>
> $tuple_col:=New collection("a";"b";"c";null;null;null;"z")
>
> I want to iterate through the collection and concatenate the values into a
> string.
>
> $str:=""
> For each ($element;$tpl_col)
>
> If ($element#Null)
>
> $str:=$str+$element
>
> End if
>
> $str:=$str+$delim
>
> End for each
>
>
> If this code is interpreted and not typed things are fine. As soon as I
> declare $element as TEXT it throws an error when I hit a Null. If I declare
> it as an object it throws an error when it hits a text. But if I declare
> $element as C_VARIANT it's all good.
>
> I suspect something like this is the motivation behind the C_VARIANT data
> type to begin with. Otherwise accomplishing this loop would get
> complicated. So here in 4D land C_VARIANT solves the problem of how we deal
> with a stream of different data types. Like a collection or object
> properties.
>
> --
> 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
> **
**
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
**
A use case for C_VARIANT
The v18 beta introduces a new variable type: variant. Not surprisingly
there is already discussion about what it could possibly be useful for and
why it doesn't have more capabilities. We are who we are.
I have come across a clear case where it's a perfect solution.
Consider a collection of text and null values. Like so:
$tuple_col:=New collection("a";"b";"c";null;null;null;"z")
I want to iterate through the collection and concatenate the values into a
string.
$str:=""
For each ($element;$tpl_col)
If ($element#Null)
$str:=$str+$element
End if
$str:=$str+$delim
End for each
If this code is interpreted and not typed things are fine. As soon as I
declare $element as TEXT it throws an error when I hit a Null. If I declare
it as an object it throws an error when it hits a text. But if I declare
$element as C_VARIANT it's all good.
I suspect something like this is the motivation behind the C_VARIANT data
type to begin with. Otherwise accomplishing this loop would get
complicated. So here in 4D land C_VARIANT solves the problem of how we deal
with a stream of different data types. Like a collection or object
properties.
--
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
**
