>> I just view that as yet another reason to change the syntax.
You're going to have to prove the new syntax better, because now you have
to justify it in the face of breaking existing code.
>>I think part of the problem here is that I'm not very well educated on
this topic yet. Perhaps you can help:
>> - If you defined a protocol Foo in user, is it referenced as user.Foo
from another ns, or user/Foo ? Or both??
user.Foo is the interface defined by the protocol, user/Foo is the protocol
information
>> - Can you have a function Foo at the same time as a protocol Foo in the
same namespace?
No.
>> - What about records? Can you have a record Foo and a protocol Foo?
No
>> - Can you have a class Foo and an protocol Foo?
Yes
Clojure and I are already confused here:
baz=> (defprotocol g (dostuff [this]))
g
baz=> g
{:on-interface baz.g, :on baz.g, :sigs {:dostuff {:doc nil, :arglists
([this]), :name dostuff}}, :var #'baz/g, :method-map {:dostuff :dostuff},
:method-builders {#'baz/dostuff #<baz$eval300$fn__301
baz$eval300$fn__301@7c2aa00c>}}
baz=> (defn g [] "a")
#'baz/g
baz=> g
#<baz$g baz$g@4bb2668f>
You can't get the protocol back it's been redefined. However the interface
baz.g still exists.
The problem is that you are confusing Java classes with Clojure Namespaces.
Clojure defines namespaces where it keeps vars (see Namespace.java in the
clojure source). So creating a protocol in Clojure does two things. 1) it
creates a java interface with the name of the protocol. 2) it defines a
hashmap assigned to a var in a Clojure namespace that describes how to find
that interface.
This is why I go back to my original comments. You are taking two
completely different concepts (interacting with Java classes, and
interacting with Clojure namespaces) and smashing them together in an
arbitrary syntax. I would assert that this is a very bad idea.
Instead let's keep separate things separate. The fact that we have Java
classes and Clojure namespaces is a fact of life when programming Clojure.
We should be educating users about the differences instead of hiding it
behind custom syntax.
Timothy
On Tue, Aug 6, 2013 at 10:41 AM, Greg <g...@kinostudios.com> wrote:
> > It's exactly the same as a normal require. Ns allows vectors/seqs
> symbols/keywords to be used interchangeably. Some people use (:require)
> others use (require), ns just uses ns/namespace to get the data on the
> first of each item after the symbol.
>
> Wow that's confusing!
>
> I just view that as yet another reason to change the syntax.
>
> To answer your question though, I'd do both syntax's a favor and interpret
> "[require [clojure.string :as c]]" using the new syntax. It would save a
> lot of newbies many headaches. Think of the newbies.
>
> > Yeah, there's a bug in the code, but let me try to redefine the problem.
> Assume I have a namespace called foo that defines a protocol (and hence an
> interface) called bar. I then also have a namespace called foo.bar. How do
> I tell the new syntax to import each? If I simply say "go get foo.bar" what
> are you going to load, the .clj file, or the java interface?
>
> I think part of the problem here is that I'm not very well educated on
> this topic yet. Perhaps you can help:
>
> - If you defined a protocol Foo in user, is it referenced as user.Foo from
> another ns, or user/Foo ? Or both??
>
> - Can you have a function Foo at the same time as a protocol Foo in the
> same namespace?
>
> - What about records? Can you have a record Foo and a protocol Foo?
>
> - Can you have a class Foo and an protocol Foo?
>
> Clojure and I are already confused here:
>
> baz=> (defprotocol g (dostuff [this]))
> g
> baz=> g
> {:on-interface baz.g, :on baz.g, :sigs {:dostuff {:doc nil, :arglists
> ([this]), :name dostuff}}, :var #'baz/g, :method-map {:dostuff :dostuff},
> :method-builders {#'baz/dostuff #<baz$eval300$fn__301
> baz$eval300$fn__301@7c2aa00c>}}
> baz=> (defn g [] "a")
> #'baz/g
> baz=> g
> #<baz$g baz$g@4bb2668f>
>
> And I'm not sure how to get the protocol back...
>
> - Greg
>
> --
> Please do not email me anything that you are not comfortable also sharing
> with the NSA.
>
> On Aug 6, 2013, at 11:43 AM, Timothy Baldridge <tbaldri...@gmail.com>
> wrote:
>
> >> >> (ns foo
> >> >> [require [clojure.string :as c]])
> >
> > >> I've never seen that before. What does it do?
> >
> > It's exactly the same as a normal require. Ns allows vectors/seqs
> symbols/keywords to be used interchangeably. Some people use (:require)
> others use (require), ns just uses ns/namespace to get the data on the
> first of each item after the symbol.
> >
> >
> > Yeah, there's a bug in the code, but let me try to redefine the problem.
> Assume I have a namespace called foo that defines a protocol (and hence an
> interface) called bar. I then also have a namespace called foo.bar. How do
> I tell the new syntax to import each? If I simply say "go get foo.bar" what
> are you going to load, the .clj file, or the java interface?
> >
> > Timothy
> >
> >
> > On Tue, Aug 6, 2013 at 9:39 AM, Phillip Lord <
> phillip.l...@newcastle.ac.uk> wrote:
> > Greg <g...@kinostudios.com> writes:
> >
> > >> I am dubious about distinguishing between lists and vectors.
> Currently,
> > >> as far as I can tell, the ns is agnostic, and only cares about them
> > >> being sequential. This is probably one of the sources of confusion for
> > >> beginners -- they see both and don't see why
> > >
> > > The reason for distinguishing between lists and vectors is as you say,
> it's
> > > confusing for beginnings. Also, it allows the syntax to have greater
> > > functionality/power.
> >
> > Really dubious about this. Having to keep in my head when I need to use
> > [] and when I need to use () is a significant problem when starting. It
> > was my realisation that for the ns declaration you don't that made
> > things easier.
> >
> > >> Also, I am confused as to how you distinguish between
> > >> [core [matrix math bs]] being equivalent to :use while
> > >> Is [one reload middleware] also :use? Or :require?
> > >
> > > Nested vectors = :use.
> > >
> > > Thus, as the comment says, [core [matrix math bs]] => (:use (core
> matrix math
> > > bs))
> > >
> > > It's a bit confusing in the current syntax (if I have it correct),
> because
> > > from it, it's not clear why "core" isn't "used".
> > >
> > > [one reload middleware]
> > >
> > > Is equivalent to:
> > >
> > > (:require [one.reload :as reload]
> > > [one.middleware :as middleware])
> >
> > Scares me to be honest. You now have an implicit alias ":as reload", and
> > are distinguishing between having an alias and having no qualification
> > by nesting or otherwise.
> >
> > I do like the idea of enforcing nesting though in
> >
> > [core [matrix math bs]]
> >
> > Phil
> >
> > --
> > --
> > You received this message because you are subscribed to the Google
> > Groups "Clojure" group.
> > To post to this group, send email to clojure@googlegroups.com
> > Note that posts from new members are moderated - please be patient with
> your first post.
> > To unsubscribe from this group, send email to
> > clojure+unsubscr...@googlegroups.com
> > For more options, visit this group at
> > http://groups.google.com/group/clojure?hl=en
> > ---
> > You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> > To unsubscribe from this group and stop receiving emails from it, send
> an email to clojure+unsubscr...@googlegroups.com.
> > For more options, visit https://groups.google.com/groups/opt_out.
> >
> >
> >
> >
> >
> > --
> > “One of the main causes of the fall of the Roman Empire was that–lacking
> zero–they had no way to indicate successful termination of their C
> programs.”
> > (Robert Firth)
> >
> > --
> > --
> > You received this message because you are subscribed to the Google
> > Groups "Clojure" group.
> > To post to this group, send email to clojure@googlegroups.com
> > Note that posts from new members are moderated - please be patient with
> your first post.
> > To unsubscribe from this group, send email to
> > clojure+unsubscr...@googlegroups.com
> > For more options, visit this group at
> > http://groups.google.com/group/clojure?hl=en
> > ---
> > You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> > To unsubscribe from this group and stop receiving emails from it, send
> an email to clojure+unsubscr...@googlegroups.com.
> > For more options, visit https://groups.google.com/groups/opt_out.
> >
> >
>
>
--
“One of the main causes of the fall of the Roman Empire was that–lacking
zero–they had no way to indicate successful termination of their C
programs.”
(Robert Firth)
--
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
