Maybe some macros can help. But if it is a good and common pattern,
then it should be included as part of the the language. One thing I am
glad to see in Clojure is it absorbed some known good macros in Common
Lisp (like "awhen" becomes "when-let") so people don't need to re-
invent the wheels agai
Seems to me an approach like this requires too much manual work. If I
know Employee have all the data fields of Person, then I know all
functions working on Person will work on Employee. That is clear and
simple.
In my view, in our programming work, maybe 80% or more time are spent
on simple thing
On Tue, May 22, 2012 at 8:29 AM, nicolas.o...@gmail.com <
nicolas.o...@gmail.com> wrote:>>
> > Why should most extensions manipulate mutable fields?
> >
> Most certainly won't. Now none of them can.
Good :)
--
You received this message because you are subscribed to the Google
Groups "Clojure"
>
> Access internal state?
>>
Like __hash in your code.
>> For example, the earlier hash example cannot be put as an extension.
>
> Why should most extensions manipulate mutable fields?
>
Most certainly won't. Now none of them can.
--
You received this message because you are subscribed to the
On Tue, May 22, 2012 at 8:04 AM, nicolas.o...@gmail.com <
nicolas.o...@gmail.com> wrote:
> And then you need to include everything accessing the internal state of
> your data structures in a big deftype with little possibility of reuse.
Access internal state?
> For example, the earlier hash exa
> The only exception is mutable fields in the type where you don't want
uncontrolled access. There you indeed need a protocol to handle the
synchronisation of the field access.
>
>
And then you need to include everything accessing the internal state of
your data structures in a big deftype with lit
It sounds like you have issue with working with something as low level as
deftype not with protocols nor how they are intended to be used. Most
people don't need to bother with equivalence or lookup - they have
defrecord.
On Monday, May 21, 2012, Mark Engelberg wrote:
> On Mon, May 21, 2012 at 4:
Hi,
Am Dienstag, 22. Mai 2012 09:01:31 UTC+2 schrieb Nicolas Oury:
>
>
> I think the whole thread is about the trade-off: some people complains
> that deftype lacks features.
>
It's not about trade-offs. It's about deftype seemingly lacking features.
> Another problem with extend is that you
My strategy here would be different, the conversion fn would be part of
the cell attributes. Maybe with the help of a lightweight factory fn to ease
record allocation.
The Convertable protocol would simply refer to the closure attribute, call it
and pass this as the unique parameter.
The reasons
Field access works just fine with extend.
On Tuesday, May 22, 2012, nicolas.o...@gmail.com wrote:
> > Everyone just reiterates the mantra “It's slower! It's slower! It's
> > slower!”, but no one talks about the trade-offs. And I bet only a very
> > small fraction ever checked what “slower” means
Bad copy & paste, forgot to remove age from the Personable def.
> On May 22, 2012 7:09 AM, "Softaddicts" wrote:
> > A better way would be something like:
> >
> > (defprotocol Personable
> >(person [this])
> > (age [this] )
> >
> > (defprotocol CensusOperators
> >(age [this]))
> >
> >
> Everyone just reiterates the mantra “It's slower! It's slower! It's
> slower!”, but no one talks about the trade-offs. And I bet only a very
> small fraction ever checked what “slower” means in their specific use
> case.
I think the whole thread is about the trade-off: some people complains
that
Hey Luc,
That's a cool casting strategy to cleanly build a standard way to get at
the person piece of any type of applicable record. In the pure composition
case, it's actually a nice solution to build functions know how to unpack
the Person aspect of a subtype.
However, I think which strateg
Hi,
Am Dienstag, 22. Mai 2012 00:08:52 UTC+2 schrieb puzzler:
> Mergeable maps are a good idea, but the current way of doing things
> steers people away from that solution and requires too much
> forethought to actively plan for reuse.
I wonder why the current way of doing things “steers away” p
On May 22, 2012 7:09 AM, "Softaddicts" wrote:
> A better way would be something like:
>
> (defprotocol Personable
>(person [this])
> (age [this] )
>
> (defprotocol CensusOperators
>(age [this]))
>
> (extend-protocol Personable
>Person
>(person [this] this)
>Employee
>(p
Interesting demonstration, except for one thing, defining getters is a waste of
time :)
When you need to define accessors, you start to run into inefficient use of
your time. It still a bearable workload in Java because of all this heavy
tooling that allows
to select for which fields accessors wi
Le 22 mai 2012 à 04:19, Mark Engelberg a écrit :
On Mon, May 21, 2012 at 4:00 PM, David Nolen wrote:
> The only two protocols that involve specifying more than 2 fns is
> IWatchable (3) and MultiFn (5). It's not clear to me that they would
> benefit from partial specification.
>
I don't think
I think it's misleading to use inheritance to reduce code duplication.
Inheritance is about indicating function typing and creating typed
contracts, both of which are fairly un-idiomatic in Clojure.
However, there is another way to prevent code duplication: use composition
instead. Instead of
On Mon, May 21, 2012 at 4:23 PM, kovas boguta wrote:
> On Mon, May 21, 2012 at 6:08 PM, Mark Engelberg
> wrote:
>
> > I never said I want inheritance. I want convenient reuse of partial
> > implementations. Inheritance is one way to achieve it, but I'd like to
> > think that Clojure can find a
On Mon, May 21, 2012 at 4:00 PM, David Nolen wrote:
> The only two protocols that involve specifying more than 2 fns is
> IWatchable (3) and MultiFn (5). It's not clear to me that they would
> benefit from partial specification.
>
I don't think there's enough body of code using protocols to real
On Mon, May 21, 2012 at 6:08 PM, Mark Engelberg
wrote:
> I never said I want inheritance. I want convenient reuse of partial
> implementations. Inheritance is one way to achieve it, but I'd like to
> think that Clojure can find a better way.
We also have macros.
You can always make your own
On Mon, May 21, 2012 at 6:08 PM, Mark Engelberg wrote:
> As I proposed in an earlier email, one brainstorm I have about this is:
>
> (get-protocol-implementation ) gives you
> back a mapping of the functions used by that type to implement that
> protocol.
>
I think there's some assumptions here
On Mon, May 21, 2012 at 11:12 AM, David Nolen wrote:
> So "real world" complex systems avoid inheritance like the plague. So
> remind me again why it's desirable?
>
> David
>
>
>
I never said I want inheritance. I want convenient reuse of partial
implementations. Inheritance is one way to achiev
Sometimes it seems to me"OO" and "inheritance" have become some kind
of taboos. I don't believe OO is all that wrong. To me Clojure seems
to have good potential to harness the good part of OO without carrying
into the bad parts. So I am hoping. :-)
On May 21, 2:25 pm, "nicolas.o...@gmail.com"
wro
>> On the other hand, defrecord/deftype encourage you to write your protocol
>> implementation in a way that cannot be reused unless you very specifically
>> plan for it (factoring the protocol implementation into a separate map) and
>> use a coding style that (might?) be less efficient (i.e., addi
On Mon, May 21, 2012 at 11:14 AM, David Nolen wrote:
> How does duck typing support sensibly extending types you don't control?
ah, i missed the implicit part of the excerpt that was about extending
rather than just use. catching up.
thanks.
--
You received this message because you are subscri
On Mon, May 21, 2012 at 2:12 PM, Raoul Duke wrote:
> On Mon, May 21, 2012 at 10:59 AM, Mark Engelberg
> wrote:
> > The whole beauty of protocols, for example, is that unlike interfaces,
> you
> > can graft it on to a type that wasn't originally designed to support it.
> > This is good, and a ste
On Mon, May 21, 2012 at 10:59 AM, Mark Engelberg
wrote:
> The whole beauty of protocols, for example, is that unlike interfaces, you
> can graft it on to a type that wasn't originally designed to support it.
> This is good, and a step forward from other languages.
i know protocols != structural t
On Mon, May 21, 2012 at 1:59 PM, Mark Engelberg wrote:
> On the other hand, defrecord/deftype encourage you to write your protocol
> implementation in a way that cannot be reused unless you very specifically
> plan for it (factoring the protocol implementation into a separate map) and
> use a codi
On Mon, May 21, 2012 at 10:12 AM, nicolas.o...@gmail.com <
nicolas.o...@gmail.com> wrote:
> The point is not whether deftype is useful or not. It is in the
> language so it must be useful, even it it is rarely.
> The point is whether it is an expressive construct or not.
> And it is not expressive
On Mon, May 21, 2012 at 1:12 PM, nicolas.o...@gmail.com <
nicolas.o...@gmail.com> wrote:
> > Same here--I can count on one hand the number of times I've wanted to
> > implement polymorphism in three and a half years. Every time
> > multimethods have worked great for the task. If you had polymorphi
> Same here--I can count on one hand the number of times I've wanted to
> implement polymorphism in three and a half years. Every time
> multimethods have worked great for the task. If you had polymorphism
> in a tight loop they might not suffice, but the decision to abandon
> multimethods should o
On Sun, May 20, 2012 at 2:37 PM, Bill Caputo wrote:
> I am not a clojure beginner (though far from feeling I know all there is to
> learn about it). I have been using clojure for almost a year; my team has
> rebuilt the central part of our system (which is relied on by just about
> every other
omputer programs, and it's totally
> > unnatural. That's just a point of view on the "natural"-ness of the
> > programming model for an individual.
> >
> > Even if most programmers think that OO is an ideal model, that still
> > doesn&
On Mon, May 21, 2012 at 11:11 AM, nicolas.o...@gmail.com <
nicolas.o...@gmail.com> wrote:
> >
> > And now any of those implementations can easily change at anytime without
> > any external considerations. So what's the problem?
>
> Well if you want to amend all of them at the same time, you have t
>
> And now any of those implementations can easily change at anytime without
> any external considerations. So what's the problem?
Well if you want to amend all of them at the same time, you have to
modify all of them.
On your advice of using extend-type: maybe I am wrong but I think it
has a pe
On Mon, May 21, 2012 at 5:39 AM, Mark Engelberg wrote:
> On Mon, May 21, 2012 at 1:53 AM, nicolas.o...@gmail.com <
> nicolas.o...@gmail.com> wrote:
> We need to figure out a way to make reusable partial implementations the
> norm. Maybe the solution is a Clojure construct along the lines of:
> (g
On Mon, May 21, 2012 at 5:39 AM, Mark Engelberg wrote:
> On Mon, May 21, 2012 at 1:53 AM, nicolas.o...@gmail.com <
> nicolas.o...@gmail.com> wrote:
>
>> I just have. This is a nice work. There is a lot of repetitions though.
>>
>
> Thanks Nicolas for putting together these examples. This is exact
On Mon, May 21, 2012 at 4:53 AM, nicolas.o...@gmail.com <
nicolas.o...@gmail.com> wrote:
> > ClojureScript? The work is done. It's all protocols.
> >
> Hi David,
>
> I just have. This is a nice work. There is a lot of repetitions though.
> For example:
> - IEquiv
> (-equiv [coll other] (equiv-seq
On Mon, May 21, 2012 at 4:53 AM, nicolas.o...@gmail.com <
nicolas.o...@gmail.com> wrote:
> >
> > Have you actually looked at the data structure implementations in
> > ClojureScript? The work is done. It's all protocols.
> >
> Hi David,
>
> I just have. This is a nice work. There is a lot of repeti
On Mon, May 21, 2012 at 1:53 AM, nicolas.o...@gmail.com <
nicolas.o...@gmail.com> wrote:
> I just have. This is a nice work. There is a lot of repetitions though.
>
Thanks Nicolas for putting together these examples. This is exactly what
I've been talking about. Whenever someone talks about the
>
> Have you actually looked at the data structure implementations in
> ClojureScript? The work is done. It's all protocols.
>
Hi David,
I just have. This is a nice work. There is a lot of repetitions though.
For example:
- IEquiv
(-equiv [coll other] (equiv-sequential coll other))
- IHash
On Sun, May 20, 2012 at 10:43 PM, Mark Engelberg
wrote:
> Until it has all been factored into protocols that make it easy for people
> to implement their own data structures that hook into Clojure's built-in
> functions, I'd say the jury's still out. Currently, Clojure uses a mixture
> of interfa
Thanks a lot for the discussions/suggestions. Maybe the Clojure way,
whatever it means, will become natural to me someday. I still remember
how awkward it was for me to use Emacs (just because I could not find
another editor to do syntax highlighting for my particular file
format), and now I canno
On Sun, May 20, 2012 at 4:31 PM, David Nolen wrote:
> Nearly all of the data structures have been ported to ClojureScript. It's
> not clear to me that we needed traits at any point.
>
> David
>
>
>
Until it has all been factored into protocols that make it easy for people
to implement their own d
On Sun, May 20, 2012 at 9:35 PM, Warren Lynn wrote:
> I hope my original "feature
> request" at the beginning falls into such category.
Don't hold your breath :) Look forward to seeing what you think further
down the line.
David
--
You received this message because you are subscribed to the
ot;natural"-ness of the
> programming model for an individual.
>
> Even if most programmers think that OO is an ideal model, that still doesn't
> mean it's the "natural" one.
>
>
>
>
>
>
>
> -Original Message-
> From: Alex Bara
Hi Warren,
"familiar" implies that your understanding relies on your previous experiences.
To get away from "familiar" concepts you need to think "out of the box".
How do you get rid of cabled thinking that brings you back always to the same
track ? Or should I say rut ?
It's an uneasy experienc
That is certainly a philosophical question to which I cannot give any
proof to my view. In my view, as long as human beings are still
writing code, you cannot be truly efficient and effective without a
language that can let you express and organize your ideas in a natural
way (which itself is subje
of the programming
model for an individual.
Even if most programmers think that OO is an ideal model, that still doesn't
mean it's the "natural" one.
-Original Message-
From: Alex Baranosky
Sender: clojure@googlegroups.com
Date: Sun, 20 May 2012 17:42:10
To:
Reply-To
I'd argue with you over whether that is the whole point of high-level
languages. I might say that high-level languages are there to make coding
more efficient and effective.
On Sun, May 20, 2012 at 5:16 PM, Warren Lynn wrote:
>
> I agree "familiar" is often mixed with "natural". But nevertheles
I agree "familiar" is often mixed with "natural". But nevertheless
that does not mean there is no such thing as "natural" thinking or
programming pattern. In a broader sense, the whole point of high-level
languages is to satisfy our need to express our ideas/logics in a more
natural way, hence the
FWIW, the first thing I did when I encountered Clojure was built a Tiny
CLOS like system with inheritance. I've since come to the conclusion it was
a waste of time and Clojure offers an equally good set of tools.
After examining a few powerful paradigms, OO, FP, LP, etc I'm not sure what
"natural"
On Sun, May 20, 2012 at 6:39 PM, nicolas.o...@gmail.com <
nicolas.o...@gmail.com> wrote:
> > So I suggest you take it to heart. Put deftype, defrecord and
> defprotocol
> > away and don't pull them back out for quite some time. At the beginning,
> > they are just a distraction from Clojure's cor
> So I suggest you take it to heart. Put deftype, defrecord and defprotocol
> away and don't pull them back out for quite some time. At the beginning,
> they are just a distraction from Clojure's core philosophy. Focus on maps,
> vectors, sets, functions, multimethods and macros.
But there are
For me learning Clojure was a real pain. It was awkward and weird and felt
wrong. But really I was just trapped in an OO-only world and didn't know
better. I don't think there is s such a thing as what is "natural" in
programming. For loops are natural? -- psha. Objects are natural? -- no
way
Thanks for the suggestion. I understand part of the joy (and pain) of
learning a new language is to change the way of thinking. So I
probably need to take on something no-trivial but also not
overwhelming to understand the issue or benefit better.
But eventually, a language cannot meet everybody's
why does defrecord and deftype exist? shouldn't deftype be sufficient?
Why is defrecord encouraged over deftype, with defype reserved for low
level bits?
it is because records can act like a generic map, which means data is
not hidden inside the type, which makes types created with defrecord
much
On May 20, 2012, at 4:23 PM, Warren Lynn wrote:
>> defrecord, deftype, and defprotocol provide extensible low level
>> abstractions like the kind Clojure is built on.
>>
>> As a Clojure programmer you should only need them rarely.
>>
>> As a beginner you should never use them.
> Well, I don't w
On Sun, May 20, 2012 at 2:23 PM, Warren Lynn wrote:
> Well, I don't want to be a beginner for too long, :-)
then "As a Clojure programmer you should only need them rarely."
> On May 20, 5:19 pm, Kevin Downey wrote:
>> On Sun, May 20, 2012 at 2:13 PM, Warren Lynn wrote:
>> > Maybe for Person/Em
On Sun, May 20, 2012 at 2:16 PM, nicolas.o...@gmail.com
wrote:
> I had wished such a feature all week.
> You don't need it often, but when you need it, it is really annoying
> to circumvent.
> traits would really be useful.
If you find yourself wanting traits you are using defrecord, deftype,
and
Well, I don't want to be a beginner for too long, :-)
On May 20, 5:19 pm, Kevin Downey wrote:
> On Sun, May 20, 2012 at 2:13 PM, Warren Lynn wrote:
> > Maybe for Person/Employee example with very simple functions do not
> > need data types, but I don't think that is generally true (isn't
> > "de
On Sun, May 20, 2012 at 2:13 PM, Warren Lynn wrote:
> Maybe for Person/Employee example with very simple functions do not
> need data types, but I don't think that is generally true (isn't
> "defrecord" trying to patching that up?). When I say "need" I am not
> saying you cannot achieve what you
I had wished such a feature all week.
You don't need it often, but when you need it, it is really annoying
to circumvent.
traits would really be useful.
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googl
On Sun, May 20, 2012 at 2:05 PM, Warren Lynn wrote:
> I don't quite understand where I introduced the rigidity. And what I
> described is not a true inheritance as in traditional OO languages
> (hence the quoted "inheritance"). It seems just some simple almost
> syntax-level change (maybe some mac
Maybe for Person/Employee example with very simple functions do not
need data types, but I don't think that is generally true (isn't
"defrecord" trying to patching that up?). When I say "need" I am not
saying you cannot achieve what you want to do without it (just as
assembly code can do anything)
I don't quite understand where I introduced the rigidity. And what I
described is not a true inheritance as in traditional OO languages
(hence the quoted "inheritance"). It seems just some simple almost
syntax-level change (maybe some macros can solve it) will make
people's life a little bit easier
On Sun, May 20, 2012 at 1:50 PM, Warren Lynn wrote:
> Thanks. That will work. But I wish things can get more concise and
> elegant.
>
> I like the Python idea of "make simple things easier and difficult
> things possible". So I think the limited "inheritance" I mentioned can
> make a large portion
On Sun, May 20, 2012 at 10:22 AM, Warren Lynn wrote:
> So from what I read the philosophy of Clojure discourages inheritance
> on concrete data types. However, maybe I am too entrenched in my OO
> thinking, how do I define a new record type that includes all the data
> members of another record t
Thanks. That will work. But I wish things can get more concise and
elegant.
I like the Python idea of "make simple things easier and difficult
things possible". So I think the limited "inheritance" I mentioned can
make a large portion of use cases easier, without sacrificing any of
Clojure's more
> (extend Employee
> AProtocol
> (merge default-implementation {:new-function (fn ...)}))
>
But you lose a bit of performance with that...
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@go
You can reuse methods by putting them in a map and then just merging it
with the new methods:
(extend Employee
AProtocol
(merge default-implementation {:new-function (fn ...)}))
The problem is that you can't reuse methods defined inline, i.e. you can't
say "my record implements
So from what I read the philosophy of Clojure discourages inheritance
on concrete data types. However, maybe I am too entrenched in my OO
thinking, how do I define a new record type that includes all the data
members of another record type? I am thinking about the classic
Employee/Person example.
73 matches
Mail list logo
