Why does funclate model.get() return the last element if the contained element is a list?

[Mike Hogan]

Hello,

I'm pondering why Model.get returns the last element if the value for the key is a list

    public <T> T get(String key) {

        T t = this.<T>getOption(key).getOrNull();

        if (t instanceof PersistentList) return (sequence(Unchecked.<PersistentList<T>>cast(t))).last();

        return t;

    }

I have a hazy memory of a chat in the past about this mirroring stringtemplate models.

It doesn't adhere to principle of least surprise, for me anyway.

I had a passing test because I was using model.get("key", String.class) and my assert passed, but in reality the underlying was a list and i have a bug.

Just wondering?

[Daniel Worthington-Bodart]

This is both a feature and a mistake! Because we support both mutable models and persistent models and the persistent models where added later we had to make persistent models follow the same contract as mutable models. 

This presents a problem as when you add something to a mutable list it adds it to the end but when you add something to persistent list it adds it to the front. 

Now the question is can we change the implementation and not break the semantic contract: I'm not sure but it's defo worth a try.

The root cause is we shouldn't support the same contract on mutable and persistent models as this is the same mistake that the Scala collections guys made.

Long term Model is dead, in fact the whole Funclate project is dead. Long live PersistentMap.

JSON support has already been ported to TL's parser combinator package, PersistentMap and PersistsentList now replace Model. The only thing left is for me to add templating support to TL. After that UtterlyIdle will drop it's dependency on StringTemplate, Antlr and Funclate!

--
You received this message because you are subscribed to the Google Groups "utterlyidle" group.
To unsubscribe from this group and stop receiving emails from it, send an email to utterlyidle...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Mike Hogan]

Awesome, that will be a lot less surprising!

On 24 Apr 2014, at 14:28, Daniel Worthington-Bodart <d...@bodar.com> wrote:

This is both a feature and a mistake! Because we support both mutable models and persistent models and the persistent models where added later we had to make persistent models follow the same contract as mutable models. 

This presents a problem as when you add something to a mutable list it adds it to the end but when you add something to persistent list it adds it to the front. 

Now the question is can we change the implementation and not break the semantic contract: I'm not sure but it's defo worth a try.

The root cause is we shouldn't support the same contract on mutable and persistent models as this is the same mistake that the Scala collections guys made.

Long term Model is dead, in fact the whole Funclate project is dead. Long live PersistentMap.

JSON support has already been ported to TL's parser combinator package, PersistentMap and PersistsentList now replace Model. The only thing left is for me to add templating support to TL. After that UtterlyIdle will drop it's dependency on StringTemplate, Antlr and Funclate!

On 24 April 2014 11:44, Mike Hogan <m...@mikehogan.net> wrote:

--
You received this message because you are subscribed to the Google Groups "utterlyidle" group.
To unsubscribe from this group and stop receiving emails from it, send an email to utterlyidle...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Daniel Worthington-Bodart]

The no deps or changing the order?

[Raymond Barlow]

Awesome to drop the deps!

[Mike Hogan]

Map and List replacing Model.  Simple, known data structures = less surprise.

The dropped deps in a bonus for me.

On 24 Apr 2014, at 15:52, Daniel Worthington-Bodart <d...@bodar.com> wrote:

The no deps or changing the order?

On 24 April 2014 15:32, Mike Hogan <m...@mikehogan.net> wrote: