5 ms·

extend does not create any kind of hierarchy, there's no subclassing going on here. if you try to set a final field you'll get an exception as expected. prote

extend does not create any kind of hierarchy, there's no subclassing going on here. if you try to set a final field you'll get an exception as expected. protected members when everything is immutable is pointless. Clojure cleanly separates values and identities.

jjs 17y ago
protected members when everything is immutable is pointless. Except when used to mark the boundary between a stable public API and an internal API that is free to change between releases.
swannodette 17y ago
@jjs, The contract is functions not members, and Clojure has a way to declare public and private fns, so what's your argument?
- jjs 17y ago
  The contract is functions not members, and Clojure has a way to declare public and private fns, so what's your argument? When I release a new major version of Foo Lib, and your program refers to private members, your program will break when I remove or rename them. Immutability won't protect you from that.
  - Raphael_Amiard 17y ago
    Except if the public api of foo lib is only functions, which is the case for all clojure libs i've worked with. EDIT: Ha, i just stumbled on this old yegge article, which is quite appropriate i think. With clojure APIs you think in verbs, so nouns are not that important http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns.html http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom... EDIT2 : perfect quote : "In the remotest regions, beyond the Functional Kingdoms, lies a fabled realm called Lambda the Ultimate. In this place it is said that there are no nouns at all, only verbs!" here you go ;)
    - jjs 17y ago
      "In the remotest regions, beyond the Functional Kingdoms, lies a fabled realm called Lambda the Ultimate. In this place it is said that there are no nouns at all, only verbs!" I already live in that Kingdom, so when I say "members", I mean member variables or member functions.

jjs 17y ago

protected members when everything is immutable is pointless. Except when used to mark the boundary between a stable public API and an internal API that is free to change between releases.

swannodette 17y ago

@jjs, The contract is functions not members, and Clojure has a way to declare public and private fns, so what's your argument?

jjs 17y ago
The contract is functions not members, and Clojure has a way to declare public and private fns, so what's your argument? When I release a new major version of Foo Lib, and your program refers to private members, your program will break when I remove or rename them. Immutability won't protect you from that.
- Raphael_Amiard 17y ago
  Except if the public api of foo lib is only functions, which is the case for all clojure libs i've worked with. EDIT: Ha, i just stumbled on this old yegge article, which is quite appropriate i think. With clojure APIs you think in verbs, so nouns are not that important http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns.html http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom... EDIT2 : perfect quote : "In the remotest regions, beyond the Functional Kingdoms, lies a fabled realm called Lambda the Ultimate. In this place it is said that there are no nouns at all, only verbs!" here you go ;)
  - jjs 17y ago
    "In the remotest regions, beyond the Functional Kingdoms, lies a fabled realm called Lambda the Ultimate. In this place it is said that there are no nouns at all, only verbs!" I already live in that Kingdom, so when I say "members", I mean member variables or member functions.