On Fri, Nov 5, 2010 at 8:23 AM, ataggart wrote:
> Do you know of a reason why (deftype [foo & more]) isn't read in as
> having two fields where the second is a seq?
>
deftype is low level and exposes limitations of the host and constructors
should not be exposed directly (add a new field, change
Do you know of a reason why (deftype [foo & more]) isn't read in as
having two fields where the second is a seq?
Barring that, would it be reasonable to disallow & as a valid field
name, thus preventing this class of error?
On Nov 4, 11:54 pm, Christophe Grand wrote:
> On Fri, Nov 5, 2010 at 1:
On Fri, Nov 5, 2010 at 1:39 AM, Mike Meyer <
mwm-keyword-googlegroups.620...@mired.org> wrote:
> It seems like the polymorphism of protocols breaks inside the
> methods. This is a problem for having a function that's polymorphic
> between an object and a container of the same objects.
>
> For inst
user=> (defn tweek* [knob] (tweek knob))
#'user/tweek*
user=> (tweek* base)
Tweeked base
nil
user=> (deftype Box [& knobs] Tune (tweek [this] (for [knob knobs]
(tweek* knob
user.Box
user=> (tweek (Box. base treble))
#
Not lexical scope, then -- it's not the deftype macro redefining it
lexicall
It seems like the polymorphism of protocols breaks inside the
methods. This is a problem for having a function that's polymorphic
between an object and a container of the same objects.
For instance:
user=> (defprotocol Tune (tweek [this]))
Tune
user=> (deftype Knob [name] Tune (tweek [this] (prin
