>
> Perhaps I'm missing something, but couldn't you take advantage of the
> numerous ways of constructing records, here, and do something like the
> following:
>
> (defrecord MyRecord [x y z])
> (defn ->MyRecord [x y z]
> (MyRecord. (* x 2) (* y 3) (* z 4)))
>
> (->My
在 2012年8月7日星期二UTC-4下午9时11分58秒，Warren Lynn写道：
>
>
> This construct is not very good. make-record is not first-class (It
>> cannot be used as an argument to a function).
>> Its first argument is not first-class (it has to be statically the
>> name of a class).
>>
>>
> Good point. I am not happy
> This construct is not very good. make-record is not first-class (It
> cannot be used as an argument to a function).
> Its first argument is not first-class (it has to be statically the
> name of a class).
>
>
Good point. I am not happy with my own version because it is a pure
run-time func
On Mon, Aug 06, 2012 at 07:32:42PM -0700, Warren Lynn wrote:
>
>
> My reluctance (or allergy as you may suggest) about OOP is toward the
> > popular
> > implementations that are insanely verbose.
> >
> >
> Why is it insanely verbose? Just look at my example:
>
> (defrecord MyRecord [x y z]
>
> (defrecord MyRecord [x y z]
> (make-record [arg1 arg2 arg3 ...] ...))
>
> (make-record MyRecord arg1 arg2 arg3 ...)
This construct is not very good. make-record is not first-class (It
cannot be used as an argument to a function).
Its first argument is not first-class (it has to be statically t
My reluctance (or allergy as you may suggest) about OOP is toward the
> popular
> implementations that are insanely verbose.
>
>
Why is it insanely verbose? Just look at my example:
(defrecord MyRecord [x y z]
(make-record [arg1 arg2 arg3 ...] ...))
(make-record MyRecord arg1 arg2 arg3 ...)
You are challenging a line of logic that only exists as a strawman, an
> expansion to the absurd -- changing the argument from one of sufficient
> flexibility to one of abstractly greater, and therefor cumulative,
> flexibility.
>
> --
> Craig Brozefsky
> Premature reification is the root o
Warren Lynn writes:
>If you say constructor is bad because it is not flexible, where "bad"
>means we should not do it at all, then what makes you think one-level
>factory function "good"? Isn't two-level factory function even more
>flexible? Then isn't three-level factory even mor
> We already have them. They are just functions.
> (And I think thinking in term of "factory" functions does not make sense.
> Every pure function takes something and makes something out of it)
>
> The construction of data from data is best taken care by functions.
> That way you don't expose
Adding complexity to a language on the basis that it fits your perception on
what is easier to read while there is already another alternative covering
several other
use cases is the central issue here.
My reluctance (or allergy as you may suggest) about OOP is toward the popular
implementations
> My answer to this is: everything is an implementation at some level. So do
> you think we need factory functions of factory functions, and factory
> functions of factory functions of factory functions? I am sure that will be
> more flexible than just one level of factory functions.
We already ha
On Sunday, August 5, 2012 7:23:55 PM UTC-4, Luc wrote:
>
> You have been referring to OOP several times in your posts, the kind of
> patterns
> we are talking about are these:
>
> http://en.wikipedia.org/wiki/Software_design_pattern
>
> These are the kind of design patterns OOP has been fond
You have been referring to OOP several times in your posts, the kind of patterns
we are talking about are these:
http://en.wikipedia.org/wiki/Software_design_pattern
These are the kind of design patterns OOP has been fond of in the last ten
years.
Java/C# and cie have been implementing/following
B) I said I hate the pattern word, let me say it bluntly, elaborate
> patterns have the unique
> property of fossilizing a language as soon as you start to modify the
> language
> to support them. Especially complex ones.
> It kills evolution the day you need to meet other nee
A) protocols provide benefits that multi dispatch don't like performance
B) I said I hate the pattern word, let me say it bluntly, elaborate patterns
have the unique
property of fossilizing a language as soon as you start to modify the
language
to support them. Especially complex o
On Sunday, August 5, 2012 1:10:04 PM UTC-4, Nicolas Oury wrote:
>
> Constructors are not a good idea, because they tie the functionality
> to the implementation.
>
>
> You want to be able to change your record to something else without
> changing your client code.
>
My answer to this is: eve
Constructors are not a good idea, because they tie the functionality
to the implementation.
You want to be able to change your record to something else without
changing your client code.
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to thi
Warren Lynn writes:
>If it does not do any harm to anybody but have benefits for some people
>(of course not just me), I reason it is a good feature.
You should check out Perl. 8^)
--
Craig Brozefsky
Premature reification is the root of all evil
--
You received this message because
On Sunday, August 5, 2012 5:56:30 AM UTC-4, Vinzent wrote:
>
> +1 for Warren's proposal. I thought about the same thing earlier, but
> haven't shared it with community because I believed it'd be rejected.
>
> Though, I don't see how OOP relates to the topic of this discussion.
> Records are not
> My point was that you don't need a factory function if there's no
> "construction logic" so the record alone - the data structure - is
> sufficient for a lot of cases. Similarly you can choose to use a
> "factory function" even if the underlying data structure is not a
> record. They are se
As I was saying, just put your factory fns in the same name space than your
defrecord and attach a doc string on it...
The sole relative "nicety" of a feature should not be the driving force helping
decide if it's worthwhile to implement. You have to consider what exists
already.
Factory fns are
In any case, here is how a record-factory function would look like
(credit goes to Chris Houser if I'm not mistaken):
(defn record-factory "A factory function for records." [recordname]
(let [recordclass ^Class (resolve (symbol recordname))
max-arg-count (apply max (map #(count (.getPa
+1 for Warren's proposal. I thought about the same thing earlier, but
haven't shared it with community because I believed it'd be rejected.
Though, I don't see how OOP relates to the topic of this discussion.
Records are not objects; they are rather typed maps. Everyone writes that
"constructor
Le 5 août 2012 à 05:33, Warren Lynn a écrit :
I don't think it is "OO-phobia". I think a lot of people here have
> used (several) OO languages and just find the FP way better - or at
> least better for the problems they are solving.
>
If I am proposing something like state-mutation based OOP,
On Sat, Aug 4, 2012 at 8:33 PM, Warren Lynn wrote:
> Simplicity is good, only when it is not too simple. Factory functions
> denitely have its value, but for more dynamic cases (so you may even create
> different record types based on the arguments). For static cases, why
> scatter the factory fun
I don't think it is "OO-phobia". I think a lot of people here have
> used (several) OO languages and just find the FP way better - or at
> least better for the problems they are solving.
>
If I am proposing something like state-mutation based OOP, that clearly
conflicts with FP and I will ju
On Saturday, August 4, 2012 9:57:55 PM UTC-4, tbc++ wrote:
>
> Warren, I can't speak for others, but I can say that personally one of the
> reasons I love Clojure so much is that it doesn't try to be a OOP language,
> instead it cleanly separates data from logic. Clojure is not a OOP language
On Sat, Aug 4, 2012 at 6:33 PM, Warren Lynn wrote:
> As difficult as you can see why I keep coming up crazy OO-like proposals, I
> am also puzzled by the seemingly OO-phobia in the community.
I don't think it is "OO-phobia". I think a lot of people here have
used (several) OO languages and just f
Warren, I can't speak for others, but I can say that personally one of the
reasons I love Clojure so much is that it doesn't try to be a OOP language,
instead it cleanly separates data from logic. Clojure is not a OOP language
and (hopefully) will never attempt to be so. But this separation of logi
> (and to be honest, Warren, I think you're beating yourself up somewhat
> by trying to shoehorn OO practices into Clojure in the first place but
> maybe that's something everyone goes thru if they are heavily steeped
> in OO thinking, when they first try to adopt an FP language?)
>
>
As diff
On Saturday, August 4, 2012 8:30:50 PM UTC-4, Luc wrote:
>
> Count me as a fan I designed and wrote complex systems in assembly
> language
> many of them above 10k lines.
>
>
I can only admire you for that. Assemly language certain has its uses, but
it is not really for average folks like m
On Sat, Aug 4, 2012 at 5:30 PM, Softaddicts wrote:
> Just use a high order fn as a factory to create your records and place it
> along you record definition in the same name space with proper documentation.
>
> High order fns can be passed around and this can be quite valuable to be able
> to spec
Count me as a fan I designed and wrote complex systems in assembly language
many of them above 10k lines.
Contrary to many commonly used languages, most assemblers have powerful macros,
that feature alone allows you to implement sophisticated designs.
As far as your OO related comments, may I poi
On Saturday, August 4, 2012 6:07:20 PM UTC-4, Jim foo.bar wrote:
>
> ok this is clearer now! I actually like what you're proposing just
> not in the form you're proposing it...since the record will already create
> 2 constructors in the underlying class, having essentially a 3rd sounds a
ok this is clearer now! I actually like what you're proposing just
not in the form you're proposing it...since the record will already
create 2 constructors in the underlying class, having essentially a 3rd
sounds a bit crowded...minimally, you want (and I agree) the ability to
optionally
>
> I am not sure I follow...If you're just creating a new record yourself,
> you can pass whatever you want to the constructor...no need for
> 'setting' whatsoever...On the other hand if you're consuming an object
> then you might need to 'set' some fields before it is useful (where doto
>
On 04/08/12 19:14, Warren Lynn wrote:
Here I am still creating immutable objects. You may say I am "setting"
things, but that is for creating a new object.
I am not sure I follow...If you're just creating a new record yourself,
you can pass whatever you want to the constructor...no need for
'
On Saturday, August 4, 2012 1:15:13 PM UTC-4, Jim foo.bar wrote:
>
> for setting up objects as you say, I'm fine using (doto Object ... ...
> ...). Records, as everything else in Clojure promote immutability and
> so setting fields doesn't really make sense unless you're consuming
> external
wrote:
My vague impression is this has been discussed somewhere, but I did
not find a ticket in Jira when searching on "record, constructor", so
I want to have some discussion here before considering entering a
ticket myself.
Often, when I create a record, I need to do some set-up
My vague impression is this has been discussed somewhere, but I did not
find a ticket in Jira when searching on "record, constructor", so I want to
have some discussion here before considering entering a ticket myself.
Often, when I create a record, I need to do some set-up more than
40 matches
Mail list logo
