librelist archives

« back to archive

Do we need a variant type?

Do we need a variant type?

From:
Paolo Redaelli
Date:
2013-02-21 @ 08:40
Tonight I update SQLite library in my forked repository
(tybor<http://github.com/tybor/Liberty/>)

Take a look at 
SQLITE_EXAMPLE<https://github.com/tybor/Liberty/blob/master/src/wrappers/database/examples/sqlite_example.e>you
can read verbose code like this (which require STRING to inherit from
ANY instead of inserting it):

feature
	entries: ARRAY[FAST_ARRAY[ANY]] is
		once
			Result := <<
							{FAST_ARRAY[ANY] <<"Linus Torvalds", create
{REFERENCE[INTEGER]}.set_item(50)>>},
							{FAST_ARRAY[ANY] <<"Richard Stallman", create
{REFERENCE[INTEGER]}.set_item(50)>>},
							{FAST_ARRAY[ANY] <<"Raphael Mack", create
{REFERENCE[INTEGER]}.set_item(24)>>}
							{FAST_ARRAY[ANY] <<"Raphael Mack", create
{REFERENCE[INTEGER]}.set_item(24)>>}
							>>
		end


Here the unavoidable reliance on run-time type identification needed by SQL
clashes with the strongly typed policy of Liberty.
I think we need a generic implementation of a variant type (please forgive
me for this VisualBasic-ism, I'm already shivering) since many libraries
implement such a type, for example GObject has GVariant, Json and so on....
Ideally we should have an insertable, expanded class with generating
features like
feature
  integer (an_integer: INTEGER): VARIANT is ..
  string (a_string: ABSTRACT_STRING) VARIANT is ..
and so on,
otherwise the above example to work require STRING and ABSTRACT_STRING to
conform to ANY, while Cyril brought convincing reasons to make strings not
heirs of ANY.

Re: Do we need a variant type?

From:
Paolo Redaelli
Date:
2013-02-21 @ 08:43
BTW, SQLITE_EXAMPLE currently require this ugly, temporary patch to
ABSTRACT_STRING to compile:

diff --git a/src/lib/string/abstract_string.e
b/src/lib/string/abstract_string.e
index 8832a9f..278b6b3 100644
--- a/src/lib/string/abstract_string.e
+++ b/src/lib/string/abstract_string.e
@@ -24,6 +24,10 @@ inherit
    SEARCHABLE[CHARACTER]
       redefine print_on, copy, out_in_tagged_out_memory,
fill_tagged_out_memory, is_equal
       end
+       ANY -- temporary (Paolo 2013-02-20)
+               redefine print_on, copy, out_in_tagged_out_memory,
fill_tagged_out_memory, is_equal
+      end
+

 insert
    PLATFORM



2013/2/21 Paolo Redaelli <paolo.redaelli@gmail.com>

> Tonight I update SQLite library in my forked repository 
(tybor<http://github.com/tybor/Liberty/>)
>
> Take a look at 
SQLITE_EXAMPLE<https://github.com/tybor/Liberty/blob/master/src/wrappers/database/examples/sqlite_example.e>you
can read verbose code like this (which require STRING to inherit from
> ANY instead of inserting it):
>
> feature
> 	entries: ARRAY[FAST_ARRAY[ANY]] is
> 		once
> 			Result := <<
> 							{FAST_ARRAY[ANY] <<"Linus Torvalds", create 
{REFERENCE[INTEGER]}.set_item(50)>>},
> 							{FAST_ARRAY[ANY] <<"Richard Stallman", create 
{REFERENCE[INTEGER]}.set_item(50)>>},
> 							{FAST_ARRAY[ANY] <<"Raphael Mack", create 
{REFERENCE[INTEGER]}.set_item(24)>>}
> 							{FAST_ARRAY[ANY] <<"Raphael Mack", create 
{REFERENCE[INTEGER]}.set_item(24)>>}
> 							>>
> 		end
>
>
> Here the unavoidable reliance on run-time type identification needed by
> SQL clashes with the strongly typed policy of Liberty.
> I think we need a generic implementation of a variant type (please forgive
> me for this VisualBasic-ism, I'm already shivering) since many libraries
> implement such a type, for example GObject has GVariant, Json and so on....
> Ideally we should have an insertable, expanded class with generating
> features like
> feature
>   integer (an_integer: INTEGER): VARIANT is ..
>   string (a_string: ABSTRACT_STRING) VARIANT is ..
> and so on,
> otherwise the above example to work require STRING and ABSTRACT_STRING to
> conform to ANY, while Cyril brought convincing reasons to make strings not
> heirs of ANY.
>

Re: [libertyeiffel] Re: Do we need a variant type?

From:
Cyril Adrian
Date:
2013-02-22 @ 08:40
 that's really unfortunate :-(




*Cyril ADRIAN** (from office)*
 [image: Google Plus] <http://plus.google.com/100388810006463519079> My
latest G+: #golang 's mock framework is simple and beautiful — and powerful
:-) <http://plus.google.com/100388810006463519079/posts/Fr6n37mZLpP>
My G+ <http://plus.google.com/100388810006463519079> -
Posts<http://plus.google.com/100388810006463519079/posts/>- Add
to Circles <http://plus.google.com/100388810006463519079/about/> - 07:59
Jan-25 <http://plus.google.com/100388810006463519079>
  Get this email app!

<http://www.wisestamp.com/apps/plus?utm_source=extension&utm_medium=email&utm_term=plus&utm_campaign=apps>

  <http://fr.linkedin.com/in/cadrian/>
  Get a signature like this.

<http://r1.wisestamp.com/r/landing?promo=35&dest=http%3A%2F%2Fwww.wisestamp.com%2Femail-install%3Futm_source%3Dextension%26utm_medium%3Demail%26utm_campaign%3Dpromo_35>
CLICK

HERE.<http://r1.wisestamp.com/r/landing?promo=35&dest=http%3A%2F%2Fwww.wisestamp.com%2Femail-install%3Futm_source%3Dextension%26utm_medium%3Demail%26utm_campaign%3Dpromo_35>


   <http://twitter.com/cadbart>  Latest tweet:
Follow @cadbart <http://twitter.com/cadbart>    • https://t.co/27cHWKRD it
starts to work! - a
bit.<http://twitter.com/cadbart/statuses/304340029801652224>
• https://t.co/WyNqZCQj eiffeltest_ng: more
traces<http://twitter.com/cadbart/statuses/303978356913885184>
• https://t.co/uMJEf6SU
oops<http://twitter.com/cadbart/statuses/303978355202613249>    View
more <http://twitter.com/cadbart>
   Get this email app!

<http://www.wisestamp.com/apps/twitter?utm_source=extension&utm_medium=email&utm_term=twitter&utm_campaign=apps>



2013/2/21 Paolo Redaelli <paolo.redaelli@gmail.com>

> BTW, SQLITE_EXAMPLE currently require this ugly, temporary patch to
> ABSTRACT_STRING to compile:
>
> diff --git a/src/lib/string/abstract_string.e
> b/src/lib/string/abstract_string.e
> index 8832a9f..278b6b3 100644
> --- a/src/lib/string/abstract_string.e
> +++ b/src/lib/string/abstract_string.e
> @@ -24,6 +24,10 @@ inherit
>     SEARCHABLE[CHARACTER]
>        redefine print_on, copy, out_in_tagged_out_memory,
> fill_tagged_out_memory, is_equal
>        end
> +       ANY -- temporary (Paolo 2013-02-20)
> +               redefine print_on, copy, out_in_tagged_out_memory,
> fill_tagged_out_memory, is_equal
> +      end
> +
>
>  insert
>     PLATFORM
>
>
>
> 2013/2/21 Paolo Redaelli <paolo.redaelli@gmail.com>
>
>> Tonight I update SQLite library in my forked repository 
(tybor<http://github.com/tybor/Liberty/>)
>>
>> Take a look at 
SQLITE_EXAMPLE<https://github.com/tybor/Liberty/blob/master/src/wrappers/database/examples/sqlite_example.e>you
can read verbose code like this (which require STRING to inherit from
>> ANY instead of inserting it):
>>
>> feature
>> 	entries: ARRAY[FAST_ARRAY[ANY]] is
>> 		once
>> 			Result := <<
>> 							{FAST_ARRAY[ANY] <<"Linus Torvalds", create 
{REFERENCE[INTEGER]}.set_item(50)>>},
>>
>>
>> 							{FAST_ARRAY[ANY] <<"Richard Stallman", create 
{REFERENCE[INTEGER]}.set_item(50)>>},
>> 							{FAST_ARRAY[ANY] <<"Raphael Mack", create 
{REFERENCE[INTEGER]}.set_item(24)>>}
>>
>>
>> 							{FAST_ARRAY[ANY] <<"Raphael Mack", create 
{REFERENCE[INTEGER]}.set_item(24)>>}
>> 							>>
>> 		end
>>
>>
>> Here the unavoidable reliance on run-time type identification needed by
>> SQL clashes with the strongly typed policy of Liberty.
>> I think we need a generic implementation of a variant type (please
>> forgive me for this VisualBasic-ism, I'm already shivering) since many
>> libraries implement such a type, for example GObject has GVariant, Json and
>> so on....
>> Ideally we should have an insertable, expanded class with generating
>> features like
>> feature
>>   integer (an_integer: INTEGER): VARIANT is ..
>>   string (a_string: ABSTRACT_STRING) VARIANT is ..
>>  and so on,
>> otherwise the above example to work require STRING and ABSTRACT_STRING to
>> conform to ANY, while Cyril brought convincing reasons to make strings not
>> heirs of ANY.
>>
>
>

Re: [libertyeiffel] Do we need a variant type?

From:
Cyril Adrian
Date:
2013-02-22 @ 08:40
 Hi Paolo,

First, please don't use ARRAY[ANY] because ANY is usually inserted, not
inherited.

You could use the classic untyped/typed pattern. I'm not sure it's the best
solution here, but… Let me sketch it a bit:

1- the untyped VARIANT

deferred class VARIANT
end


2- the typed VARIANT

class TYPED_VARIANT[E_]

inherit
   VARIANT

create {ANY}
   make

feature {ANY}
   item: E_

feature {}
   make (a_item: like item) is
      do
         item := a_item
      end
end


3- a specific ANY operator

class ANY
...
feature {ANY}
   prefix "???", as_variant: VARIANT is
      do
         create {TYPED_VARIANT[like Current]} Result.make
      end
end


I don't like putting that into ANY, because you cannot put any kind of
object in a database… Maybe some specific "VARIANTABLE" class inserted by
types that can be put in database? (strings, numbers, dates, what else?)

I have no idea for the prefix operator :-/ Maybe prefix "*" ?

Also: did you look at EDC? (ESE's Eiffel Database Connection I wrote a few
years ago) There could be ideas in there too, although the whole beast is a
bit complex.

   - code:
   http://ese.svn.sourceforge.net/viewvc/ese/trunk/src/eiffel/lib/edc/
   - examples: http://ese.svn.sourceforge.net/viewvc/ese/trunk/tutorial/edc/
(well
   unfortunately only one example…)


What do you think?

Cheers,



*Cyril ADRIAN** (from office)*
  <http://fr.linkedin.com/in/cadrian/>
  Get a signature like this.

<http://r1.wisestamp.com/r/landing?promo=35&dest=http%3A%2F%2Fwww.wisestamp.com%2Femail-install%3Futm_source%3Dextension%26utm_medium%3Demail%26utm_campaign%3Dpromo_35>
CLICK

HERE.<http://r1.wisestamp.com/r/landing?promo=35&dest=http%3A%2F%2Fwww.wisestamp.com%2Femail-install%3Futm_source%3Dextension%26utm_medium%3Demail%26utm_campaign%3Dpromo_35>


   <http://twitter.com/cadbart>  Latest tweet:
Follow @cadbart <http://twitter.com/cadbart>    • https://t.co/27cHWKRD it
starts to work! - a
bit.<http://twitter.com/cadbart/statuses/304340029801652224>
• https://t.co/WyNqZCQj eiffeltest_ng: more
traces<http://twitter.com/cadbart/statuses/303978356913885184>
• https://t.co/uMJEf6SU
oops<http://twitter.com/cadbart/statuses/303978355202613249>    View
more <http://twitter.com/cadbart>
   Get this email app!

<http://www.wisestamp.com/apps/twitter?utm_source=extension&utm_medium=email&utm_term=twitter&utm_campaign=apps>



2013/2/21 Paolo Redaelli <paolo.redaelli@gmail.com>

> Tonight I update SQLite library in my forked repository 
(tybor<http://github.com/tybor/Liberty/>)
>
> Take a look at 
SQLITE_EXAMPLE<https://github.com/tybor/Liberty/blob/master/src/wrappers/database/examples/sqlite_example.e>you
can read verbose code like this (which require STRING to inherit from
> ANY instead of inserting it):
>
> feature
> 	entries: ARRAY[FAST_ARRAY[ANY]] is
> 		once
> 			Result := <<
> 							{FAST_ARRAY[ANY] <<"Linus Torvalds", create 
{REFERENCE[INTEGER]}.set_item(50)>>},
>
> 							{FAST_ARRAY[ANY] <<"Richard Stallman", create 
{REFERENCE[INTEGER]}.set_item(50)>>},
> 							{FAST_ARRAY[ANY] <<"Raphael Mack", create 
{REFERENCE[INTEGER]}.set_item(24)>>}
>
> 							{FAST_ARRAY[ANY] <<"Raphael Mack", create 
{REFERENCE[INTEGER]}.set_item(24)>>}
> 							>>
> 		end
>
>
> Here the unavoidable reliance on run-time type identification needed by
> SQL clashes with the strongly typed policy of Liberty.
> I think we need a generic implementation of a variant type (please forgive
> me for this VisualBasic-ism, I'm already shivering) since many libraries
> implement such a type, for example GObject has GVariant, Json and so on....
> Ideally we should have an insertable, expanded class with generating
> features like
> feature
>   integer (an_integer: INTEGER): VARIANT is ..
>   string (a_string: ABSTRACT_STRING) VARIANT is ..
>  and so on,
> otherwise the above example to work require STRING and ABSTRACT_STRING to
> conform to ANY, while Cyril brought convincing reasons to make strings not
> heirs of ANY.
>

Re: [libertyeiffel] Do we need a variant type?

From:
Raphael Mack
Date:
2013-02-22 @ 19:50
Hi,

oh, I was not aware anymore of EDC. I took a short tour through the code
and I'm convinced, that the pattern Cyril described is fit's quite well.
(You did a nice job in EDC!)

And automatic conversion from types like INTEGER into database types is
not really necessary, in my eyes. I think it would be good to have two
DB interfaces on top of the wrappers: one very simple, which treats
every type as STRING, and one high level which is as comfortable as EDC.
BTW cyril, why do you think EDC is a big beast? In a DB-centric
application I think this is a perfect approach. But yes, for the small
app which just wants to log some data into a database it seems
over-sized. Therefore I think a second, untyped leg upon the same
wrapper would be nice. This could be near to the eiffel-libraries code,
but replaced ANY by STRING.

Regards,
Rapha

Re: [libertyeiffel] Do we need a variant type?

From:
Cyril Adrian
Date:
2013-02-23 @ 13:56
Hi,

2013/2/22 Raphael Mack <ramack@raphael-mack.de>

> oh, I was not aware anymore of EDC. I took a short tour through the code
> and I'm convinced, that the pattern Cyril described is fit's quite well.
> (You did a nice job in EDC!)
>

Thanks, even if I am not sure myself ;-)


BTW cyril, why do you think EDC is a big beast? In a DB-centric
> application I think this is a perfect approach.


Maybe because I found it quite difficult to write correctly (AFAIR there
are a lot of subtle bugs) but if you say it's interesting then I'll put a
bit of brain in there sometime :-)


Therefore I think a second, untyped leg upon the same
> wrapper would be nice. This could be near to the eiffel-libraries code,
> but replaced ANY by STRING.
>

Good idea! I like it.

There are also Eiffel conversions, although I don't known when those will
be implemented in Liberty (certainly not now) :-)

Cheers,

*Cyril A**DRIAN*

[image: Facebook] <https://www.facebook.com/cyril.adrian> [image:
Twitter]<https://twitter.com/cadbart> [image:
LinkedIn] <http://fr.linkedin.com/in/cadrian/> [image: Google
Plus]<https://plus.google.com/u/0/100388810006463519079>
Contact me: [image: Google Talk] cyril.adrian@gmail.com
   [image: Twitter] <http://twitter.com/cadbart>  Latest tweet:
https://t.co/27cHWKRD it starts to work! - a bit. Follow
@cadbart<http://twitter.com/cadbart>

Reply<http://twitter.com/?status=@cadbart&in_reply_to=cadbart&in_reply_to_status_id=304340029801652200>
Retweet <http://twitter.com/?status=RT @cadbart: https://t.co/27cHWKRD it
starts to work! - a bit.> 22:21
Feb-20<http://twitter.com/cadbart/statuses/304340029801652224>
  Get this email app!

<http://www.wisestamp.com/apps/twitter?utm_source=extension&utm_medium=email&utm_term=twitter&utm_campaign=apps>

  Free signature tool.

<http://r1.wisestamp.com/r/landing?promo=32&dest=http%3A%2F%2Fwww.wisestamp.com%2Femail-install%3Futm_source%3Dextension%26utm_medium%3Demail%26utm_campaign%3Dpromo_32>
CLICK
HERE TO GET 
IT.<http://r1.wisestamp.com/r/landing?promo=32&dest=http%3A%2F%2Fwww.wisestamp.com%2Femail-install%3Futm_source%3Dextension%26utm_medium%3Demail%26utm_campaign%3Dpromo_32>

Re: [libertyeiffel] Do we need a variant type?

From:
Raphael Mack
Date:
2013-02-23 @ 17:37
Am Samstag, den 23.02.2013, 14:56 +0100 schrieb Cyril ADRIAN: 
> There are also Eiffel conversions, although I don't known when those
> will be implemented in Liberty (certainly not now) :-)

I think automatic conversion is evil. Ok, for integers without loss
(i.e. conversion to the bigger type) I have no problem with it, but I
dislike the general solution (which also has its charm) as it implicitly
executes code for a simple assignment - which could e. g. allocate
memory and therefore fail at runtime. 
Cheers,
Rapha

Re: [libertyeiffel] Do we need a variant type?

From:
Cyril Adrian
Date:
2013-02-23 @ 18:32
2013/2/23 Raphael Mack <ramack@raphael-mack.de>

> Am Samstag, den 23.02.2013, 14:56 +0100 schrieb Cyril ADRIAN:
> > There are also Eiffel conversions, although I don't known when those
> > will be implemented in Liberty (certainly not now) :-)
>
> I think automatic conversion is evil.


I don't know about eveil, but dangerous, yes it is. I know your argument
(that's the same one Dominique used). On the other hand it is quite useful,
all the more with the strength of Liberty's garbage collector.

Maybe it could be available as an option?

Anyway… not now ;-)

Cheers,

*Cyril A**DRIAN*

[image: Facebook] <https://www.facebook.com/cyril.adrian> [image:
Twitter]<https://twitter.com/cadbart> [image:
LinkedIn] <http://fr.linkedin.com/in/cadrian/> [image: Google
Plus]<https://plus.google.com/u/0/100388810006463519079>
Contact me: [image: Google Talk] cyril.adrian@gmail.com
   [image: Twitter] <http://twitter.com/cadbart>  Latest tweet:
https://t.co/fI80INx4UV those generated files should not have been
commited Follow
@cadbart <http://twitter.com/cadbart>

Reply<http://twitter.com/?status=@cadbart&in_reply_to=cadbart&in_reply_to_status_id=305321035228643300>
Retweet <http://twitter.com/?status=RT @cadbart: https://t.co/fI80INx4UV
those generated files should not have been commited> 15:19
Feb-23<http://twitter.com/cadbart/statuses/305321035228643328>
  Get this email app!

<http://www.wisestamp.com/apps/twitter?utm_source=extension&utm_medium=email&utm_term=twitter&utm_campaign=apps>

  Free signature tool.

<http://r1.wisestamp.com/r/landing?promo=32&dest=http%3A%2F%2Fwww.wisestamp.com%2Femail-install%3Futm_source%3Dextension%26utm_medium%3Demail%26utm_campaign%3Dpromo_32>
CLICK
HERE TO GET 
IT.<http://r1.wisestamp.com/r/landing?promo=32&dest=http%3A%2F%2Fwww.wisestamp.com%2Femail-install%3Futm_source%3Dextension%26utm_medium%3Demail%26utm_campaign%3Dpromo_32>

Re: [libertyeiffel] Do we need a variant type?

From:
Raphael Mack
Date:
2013-02-23 @ 18:55
Am Samstag, den 23.02.2013, 19:32 +0100 schrieb Cyril ADRIAN: 
> 2013/2/23 Raphael Mack <ramack@raphael-mack.de>
>         Am Samstag, den 23.02.2013, 14:56 +0100 schrieb Cyril ADRIAN: 
>         > There are also Eiffel conversions, although I don't known
>         when those
>         > will be implemented in Liberty (certainly not now) :-)

>         I think automatic conversion is evil. 

> I don't know about eveil, but dangerous, yes it is. I know your
> argument (that's the same one Dominique used). On the other hand it is
> quite useful, all the more with the strength of Liberty's garbage
> collector.

Maybe it is from Dominique ;-) But at work I'm working on embedded
systems with safety relevant functionality and this somehow also forms
my opinion. I want as much as simple clear and understandable
behavior... I even dislike caches, CPU pipelines and all this stuff. But
yes, without all those it would be impossible to build todays systems.
So we'll probably have to learn to live with all this "magic".
Conversion with 3 options: "none", "only safe", "all" and tree different
warning levels would be cool!
Every beginner shall start without conversion until he knows its impact
by heart.

Regards,
Rapha 

Re: [libertyeiffel] Do we need a variant type?

From:
Paolo Redaelli
Date:
2013-02-23 @ 19:43
Il 23/02/2013 19:55, Raphael Mack ha scritto:
> Am Samstag, den 23.02.2013, 19:32 +0100 schrieb Cyril ADRIAN:
>> 2013/2/23 Raphael Mack <ramack@raphael-mack.de>
>>          Am Samstag, den 23.02.2013, 14:56 +0100 schrieb Cyril ADRIAN:
>>          > There are also Eiffel conversions, although I don't known
>>          when those
>>          > will be implemented in Liberty (certainly not now) :-)
>>          I think automatic conversion is evil.
>> I don't know about eveil, but dangerous, yes it is. I know your
>> argument (that's the same one Dominique used). On the other hand it is
>> quite useful, all the more with the strength of Liberty's garbage
>> collector.
I would rather say that automatic *casts* are evil... in fact you agreed 
with convertion to a bigger type.
Turning an integer into a smaller type is a constraint
> Maybe it is from Dominique ;-) But at work I'm working on embedded
> systems with safety relevant functionality and this somehow also forms
> my opinion. I want as much as simple clear and understandable
> behavior... I even dislike caches, CPU pipelines and all this stuff. But
> yes, without all those it would be impossible to build todays systems.
> So we'll probably have to learn to live with all this "magic".
> Conversion with 3 options: "none", "only safe", "all" and tree different
> warning levels would be cool!
That's the way to go; actually Cyril and I agreed some months ago on 
"enable all the convertions", "convertions are turned into warning" and 
"no convertions at all", with "no convertions" as default.

Re: [libertyeiffel] Do we need a variant type?

From:
Cyril Adrian
Date:
2013-02-24 @ 09:40
2013/2/23 Paolo Redaelli <paolo.redaelli@gmail.com>

> That's the way to go; actually Cyril and I agreed some months ago on
> "enable all the convertions", "convertions are turned into warning" and "no
> convertions at all", with "no convertions" as default.
>

I don't remember… but at least it means I have a consistent mind on the
subject ;-)

cheers


 *Cyril A**DRIAN*

[image: Facebook] <https://www.facebook.com/cyril.adrian> [image:
Twitter]<https://twitter.com/cadbart> [image:
LinkedIn] <http://fr.linkedin.com/in/cadrian/> [image: Google
Plus]<https://plus.google.com/u/0/100388810006463519079>
Contact me: [image: Google Talk] cyril.adrian@gmail.com
   [image: Twitter] <http://twitter.com/cadbart>  Latest tweet:
https://t.co/fI80INx4UV those generated files should not have been
commited Follow
@cadbart <http://twitter.com/cadbart>

Reply<http://twitter.com/?status=@cadbart&in_reply_to=cadbart&in_reply_to_status_id=305321035228643300>
Retweet <http://twitter.com/?status=RT @cadbart: https://t.co/fI80INx4UV
those generated files should not have been commited> 15:19
Feb-23<http://twitter.com/cadbart/statuses/305321035228643328>
  Get this email app!

<http://www.wisestamp.com/apps/twitter?utm_source=extension&utm_medium=email&utm_term=twitter&utm_campaign=apps>

  Free signature tool.

<http://r1.wisestamp.com/r/landing?promo=32&dest=http%3A%2F%2Fwww.wisestamp.com%2Femail-install%3Futm_source%3Dextension%26utm_medium%3Demail%26utm_campaign%3Dpromo_32>
CLICK
HERE TO GET 
IT.<http://r1.wisestamp.com/r/landing?promo=32&dest=http%3A%2F%2Fwww.wisestamp.com%2Femail-install%3Futm_source%3Dextension%26utm_medium%3Demail%26utm_campaign%3Dpromo_32>

Re: [libertyeiffel] Do we need a variant type?

From:
Paolo Redaelli
Date:
2013-02-24 @ 13:06
2013/2/24 Cyril ADRIAN <cyril.adrian@gmail.com>

>
> 2013/2/23 Paolo Redaelli <paolo.redaelli@gmail.com>
>
>> That's the way to go; actually Cyril and I agreed some months ago on
>> "enable all the convertions", "convertions are turned into warning" and "no
>> convertions at all", with "no convertions" as default.
>>
>
> I don't remember… but at least it means I have a consistent mind on the
> subject ;-)
>
>
We discussed about it when writing
https://github.com/LibertyEiffel/Liberty/wiki/Liberty-plan  :
*convert: this is quite useful; I would add “—convertion-are-warnings”
“—convertion-are-errors” flags to the compiler because automatic convertion
can have serious impact of perfomance of produced programs (ask me
benchmarks on 64bit integers).*
as usual my memory is not good: it were not "some months ago", it were two
years ago....

Re: [libertyeiffel] Do we need a variant type?

From:
Paolo Redaelli
Date:
2013-02-23 @ 08:21
2013/2/22 Raphael Mack <ramack@raphael-mack.de>

> Hi,
>
> oh, I was not aware anymore of EDC. I took a short tour through the code
> and I'm convinced, that the pattern Cyril described is fit's quite well.
> (You did a nice job in EDC!)
>
I got mixed feeling when reading the code of EDC and its example but I
recognize it's due to my path to IT and my limits: I am fundamentally a
less-than-average "hobbist programmer, wannabe full-time", I never got
theoretical courses on programming and picked a non-programming university
(civil structural engineering, yes, like Bin Laden). I started with Basic
on Commodore 64 (avidly reading when 8-years old a 20 lesson course bought
at a kiosk), then ARexx on Amiga, C and E on Amiga (having digested some
books on the argument); at that time I met Rudi Chiarito who ported
SmallEiffel -0.7x on Amiga who suggested me to study Python and Eiffel.
Both hooked me.
With this verbose backgroud the engineer in me really acknowledges the rich
design, while the Amiga-user who learnt Python in me which still stick to
"keep-it-simple-sir"/"keep it lean and efficient", typical Amiga rants, has
a strong, distinct impression that that's an overdesign.
Mind it, the rational part of me is sure that it is *NOT* too much
complexity when designing a corporate IT system being used by thousands of
users at the same time.

And automatic conversion from types like INTEGER into database types is
> not really necessary, in my eyes. I think it would be good to have two
> DB interfaces on top of the wrappers: one very simple, which treats
> every type as STRING, and one high level which is as comfortable as EDC.
>
This sounds reasonable as it is within our reach. That's actually the very
same path taken by SQLite: version 2 treated everything like a string,
while version 3 allow more strong typing along with a casual-typing policy
(if I recall correctly)

BTW cyril, why do you think EDC is a big beast? In a DB-centric
> application I think this is a perfect approach. But yes, for the small
> app which just wants to log some data into a database it seems
> over-sized. Therefore I think a second, untyped leg upon the same
> wrapper would be nice. This could be near to the eiffel-libraries code,
> but replaced ANY by STRING.
>
> Good. I still would introduce VARIANT and VARIATABLE into standard library
as it is required for all libraries based on Glib (GVariant) or on GOBject
(GValue), like Gnome DB (http://www.gnome-db.org/ ).

I'm still puzzled why GObject guys implemented GValue which looks to me as
a duplicate of GLib's GVariant.

As an ending note, in the time I wrote this answer Cyril would have
reimplemented an actual compiler....

Re: [libertyeiffel] Do we need a variant type?

From:
Paolo Redaelli
Date:
2013-02-23 @ 07:36
2013/2/22 Cyril ADRIAN <cyril.adrian@gmail.com>

> Hi Paolo,
>
> First, please don't use ARRAY[ANY] because ANY is usually inserted, not
> inherited.
>
I knew that the design wasn't optimal. At that time, more or less 5 years
ago, we were recovering from the design quarrels that caused the divertions
of ISE Eiffel and SmartEiffel.
STRING were still an heir of ANY.... I changed STRING in order to compile
something and test there were no other issues.


>
> You could use the classic untyped/typed pattern. I'm not sure it's the
> best solution here, but…
>
I *do *agree, I've read your notes (in PATTERN.txt) about the typed
derivation pattern, I was going to make the same proposal.


> Let me sketch it a bit:
>
> 3- a specific ANY operator
>
> class ANY
> ...
> feature {ANY}
>    prefix "???", as_variant: VARIANT is
>       do
>          create {TYPED_VARIANT[like Current]} Result.make
>       end
> end
>
>
> I don't like putting that into ANY, because you cannot put any kind of
> object in a database… Maybe some specific "VARIANTABLE" class inserted by
> types that can be put in database? (strings, numbers, dates, what else?)
>



>
> I have no idea for the prefix operator :-/ Maybe prefix "*" ?
>
<Joking> Oh no! we will end with code identical to C!</Joking>
When we will have automatic convertion we would not need any operator at
all as any VARIANTABLE class will be convertible into a VARIANT with
as_variant.

/me looks at his keyboard mumbling

What about prefix "%"? AFAIK "%" used as a placeholder in SQL, and VARIANT
will be used to fill that placeholder.


>  Also: did you look at EDC? (ESE's Eiffel Database Connection I wrote a
> few years ago) There could be ideas in there too, although the whole beast
> is a bit complex.
>

Ohh juicy, tasty code :-)


> What do you think?
>
Everything you wrote is fine; I would only add that VARIANT will also the
natural heir of GVariant (from Glib
http://developer.gnome.org/glib/stable/glib-GVariantType.html
http://developer.gnome.org/glib/stable/glib-GVariant.html ); and I'm pretty
sure I have encountered at least another library implementing the variant
concept/design pattern but I currently don't remember its name.