going nutty with types

[Raoul Duke]

hi,

doing ios development. bug fixing, only. learning that some
pre-existing code was doing it all wrong to begin with, i had to move
it to another method that fires in another part of the overall UI
lifecycle. makes me wonder if it would be nice to have a setup where
the types were used to restrict what could be done during parts of the
lifecycle. so if you have a ui View, in code the methods should see
the same underlying object go through different types, like
PreLayoutView, PreDrawView, and AliveView, or something like that.
each of those apis would be restricted to what is supposed to be
allowed vs. disallowed during that phase of the view lifecycle.

</random thought>

[David-Sarah Hopwood]

Doable using a typestate system, but it does complicate the type system
significantly. I'm a fan of typestate, but you have to consider whether
the complication is worth it given the goals for your language, your
complexity budget for the type system given what other features it has, etc.

--
David-Sarah Hopwood ⚥

[Raoul Duke]

On Tue, Oct 16, 2012 at 3:31 PM, David-Sarah Hopwood
<davidsara...@googlemail.com> wrote:
> Doable using a typestate system, but it does complicate the type system
> significantly.

thanks for the note, i'll see if i can learn about that.

being a low-powered programmer, i was thinking of just a brute force
approach where (now, you can't completely prevent people from screwing
themselves, so there are holes in this, of course) ui code doesn't get
to keep references to things, so methods are always passed in
("injected", ugh) whatever they need, possibly a directory from which
to get references. those directories would be typed depending on the
particular lifecycle phase the method can be called in. so you can't
get anything with layout calls before the layout phase is
started/done.

something as lame as objective-c could even do things this way i think
off the top of my head.

of course, most programmers looking at such an approach would barf and
riot if told to use it because of the overhead involved.

["Ionuț G. Stan"]

I'm not sure I understood you correctly, but I once felt the need for
something similar when working with GWT. I wanted a way to have the type
system stop me mutating DOM nodes that haven't been inserted into the
actual page yet. I wanted something like an AttachedNode and a
DetachedNode. The AttachedNode type would have provided more methods.
The GWT way was to throw runtime exceptions.

In retrospect maybe even a single Node type would have been okay if it
was to use phantom types for the attach state. Similar to the flight
example in this article[0]. And the only way to create these labeled
nodes would have been through factories.

Node<Detached> detached = document.createElement();
Node<Attached> attached = document.appendChild(div);

Anyways, in this example both instances would have the same set of
methods, so it would require another object that performs actions on
nodes (if we want more type safety). Some of this new object's methods
would accept only attached nodes, some only detached, and some would
accept both.


[0]: http://gabrielsw.blogspot.com/2012/09/phantom-types-in-java.html

--
Ionuț G. Stan | http://igstan.ro

[Raoul Duke]

On Tue, Oct 16, 2012 at 4:25 PM, "Ionuț G. Stan"

> system stop me mutating DOM nodes that haven't been inserted into the actual page yet.

yup, like that.

[David Barbour]

Linear types or dependent types are both able to enforce this sort of lifecycle. It may be useful to think of a lifecycle as a protocol. Staged metaprogramming, e.g. via monads, can also enforce the sort of constraints you're considering.

David-Sarah suggests typestate, but typestate is not composable and results in much accidental complexity. I consider typestate a flawed concept.

Anyhow, your question seems to be framed with imperative, stateful construction in mind. The issues with lifecycle might be avoided entirely with different abstractions for UI. 

Regards,

Dave

--
send mail     : pi...@googlegroups.com
unsubscribe   : pilud+un...@googlegroups.com
home page     : http://groups.google.com/group/pilud
subscribe     : send a short post to   denis <dot> spir <at> gmail <dot> com
Note: reply address is set to the list -- no need to "reply all"

--
bringing s-words to a pen fight

[Raoul Duke]

On Wed, Oct 17, 2012 at 11:32 AM, David Barbour <dmba...@gmail.com> wrote:
> Anyhow, your question seems to be framed with imperative, stateful
> construction in mind. The issues with lifecycle might be avoided entirely
> with different abstractions for UI.

guilty as charged, and very much looking forward to the day Google,
Apple, or whoever else Pretty Much Runs The Entire Effing Planet
actually ships with non-imperative bullpucky. :-)

[Raoul Duke]

On Wed, Oct 17, 2012 at 11:32 AM, David Barbour <dmba...@gmail.com> wrote:

> Linear types or dependent types are both able to enforce this sort of
> lifecycle.

my new bumper sticker:
http://www.cafepress.com/cp/customize/product2.aspx?from=CustomDesigner&number=709770338

(dunno how long that url will live.)