Sure, put this into a repl:

(ns foo)

(defprotocol IBar
  (do-stuff [this]))

(ns user
  (require [foo])
  (import [foo IBar]))

(class foo/IBar)
(class foo.IBar)


If this syntax were unified into something like you suggest we have a
problem:

(ns user
  [foo IBar]) ;; What is IBar, a class or a var?

Timothy


On Tue, Aug 6, 2013 at 10:56 AM, Greg <g...@kinostudios.com> wrote:

> >> 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?
>
> It would also help to have an example of how it's currently done.
>
> - Greg
>
> --
> Please do not email me anything that you are not comfortable also sharing
> with the NSA.
>
> On Aug 6, 2013, at 12:41 PM, 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.


Reply via email to