Performace was an issue right from the start for this project, that's
why I went down the protocol/record path instead of
multi-methods...surely, this is a decision to be made in the beginning,
isn't it?
I did take into account all the comments so far...my world is now fully
immutable, reset!
You keep talking about performance. I'm a long way from being a clojure
expert, but one thing I *do* know is that premature optimization is the
root of many many evils.
May I suggest you first get your app working, in a clean understandable
fashion, ideally with some solid unit tests. Then, and o
On 14 June 2012 11:17, Jim - FooBar(); wrote:
> On 14/06/12 06:38, Philip Potter wrote:
>>
>>
>> Another reason the interface exists is for interoperability - if you want
>> a java class to participate in the protocol, you do it by implementing the
>> corresponding interface.
>>
>> Phil
>>
>
> Peo
On 14/06/12 06:38, Philip Potter wrote:
Another reason the interface exists is for interoperability - if you
want a java class to participate in the protocol, you do it by
implementing the corresponding interface.
Phil
People suggested that I should not consume the interface produced by a
On 14/06/12 07:27, Tassilo Horn wrote:
I quickly glanced over your code. Why do you still have `undo`? That
shouldn't be needed in a fully immutable world. If you make a move just
for trying out, then simply don't reset! your atom with the new value of
the current board.
Undo is still there
On 14/06/12 10:01, nicolas.o...@gmail.com wrote:
There should not be any atom in this. The function would be more
reusable if it take a board and return
a board without changing any atom.
(You will still be to express the atom change around it but you could
also use to try and build a tree withou
> (defn move
> "The function responsible for moving Pieces. Each piece knows how to move
> itself. If trying? is true, there will be no histiry of the new state of the
> board. Returns the new board."
> ^clojure.lang.PersistentVector
> [game mappings p coords]
> {:pre [(satisfies? Piece p)]} ;saf
"Jim - FooBar();" writes:
> On the upside I did not have to change much and now at least it reads
> nicer...however, on the down side executing a single move takes
> roughly double the time (~ 13ms instead of ~8ms before)...
I quickly glanced over your code. Why do you still have `undo`? That
On Jun 12, 2012 7:41 PM, "Alan Malloy" wrote:
>
> On Jun 12, 5:56 am, "Jim - FooBar();" wrote:
> > On 12/06/12 13:53, Jim - FooBar(); wrote:
> >
> > > On 12/06/12 13:47, Meikel Brandmeyer (kotarak) wrote:
> > >> If update-position is a protocol function just call it without the
> > >> dot. Just l
Right,
so I followed every ones' suggestions and went fully immutable! points
are now regular vectors and updating position returns a brand new piece
(as does killing a piece, it changes its meta-data). On the upside I did
not have to change much and now at least it reads nicer...however, on
Ok after a cup of tea I'm starting to realize i can easily do something
like:
(let [moved (update-position p coords)] ;no mutation - returns a new piece
(filter (complement dead?)
(-> board
(dissoc (getListPosition p)) ;get rid of
the old piece
(assoc (getListP
On 13/06/12 17:22, nicolas.o...@gmail.com wrote:
For example, if your state were a vector [:x :o :x nil :x]
(for a board of tic-tac-toe), calling (assoc board 3 :x) will return a
new board
with the position 3 set to :x.
Yes but in tic-tac-toe you are inserting pieces while in chess/checker
> you mean making 32 new pieces after each move regardless of whether they
> moved or not? how can I identify the ones that are different from the ones
> that remain unchanged so i can conj them in a new list? move will eventually
> call 'build-board' which has to look somewhere for the current pie
"Jim - FooBar();" writes:
>> If the things you store in atoms or refs aren't immutable, then the
>> guarantees made by those reference types simply don't apply.
>
> hmmm...I see what you mean. I'll try to rethink my design... In fact,
> I was wondering in the beggining of this project whether I n
On 13/06/12 11:21, Tassilo Horn wrote:
I don't get this. If you have your current-board as an atom containing
a collection of pieces, and every piece's location can be mutated by
(updatePosition piece ...), then doing that does change the world, i.e.,
the location of piece changed without having
> different positions now or some are nil (dead))... if i make the pieces pure
> what comes to mind is resetting or swapping possibly 32 atoms instead..
No, you will have an atom containing a new board with new pieces in
their new position.
(By the way, you can go a long way writing what you want
"Jim - FooBar();" writes:
Hi Jim,
> In other words, moves are also records that satisfy the Command
> protocol which says there should exist an "execute" and an "undo"
> method in all implementors...that way, each move knows how to execute
> itself but also how to undo itself and return to the s
On 13/06/12 10:58, nicolas.o...@gmail.com wrote:
And from what I understand of your design, I disagree on a point: I
think it is not true a move is a command apply to
a piece. A lot of moves involve multiple pieces.
So I would try to represent a move as something like:
(defprotocol
Move
On Wed, Jun 13, 2012 at 10:46 AM, nicolas.o...@gmail.com
wrote:
> that mutation inside piece is
>> the only non-functional detail...everything else I am indeed returning new
>> boards, new pieces (promotion, death etc)...
>>
>
And from what I understand of your design, I disagree on a point: I
th
that mutation inside piece is
> the only non-functional detail...everything else I am indeed returning new
> boards, new pieces (promotion, death etc)...
>
If I were you, I would look into a way to make Pieces pure too.
Because their mutability cascades into the whole state and makes the descript
First of all, thanks all of you for your helpful and often enlightening
comments
On 13/06/12 08:13, Tassilo Horn wrote:
But probably that's not a good approach. When mutating the positions in
a move, there's no way back. If everything was immutable, i.e.,
updatePosition would return a ne
"Jim - FooBar();" writes:
>> What's update-position? Shouldn't that be (updatePosition p coords),
>> as you say IPieces have an updatePosition method? And since you use
>> that for side effects (you don't use the return value), are your
>> IPiece implementors actually deftypes with :volatile-mu
On 13 June 2012 06:34, Michał Marczyk wrote:
> Not really -- only primitive type hints actually prevent the function
> from accepting a non-matching argument:
Should have added a primitive hint example:
(defn foo [^long x] x)
(foo {})
; ClassCastException
M.
--
You received this message beca
On 12 June 2012 22:00, Jim - FooBar(); wrote:
> On 12/06/12 19:41, Alan Malloy wrote:
>>
>> It's not just less convenient, but genuinely incorrect to use dot-
>> notation for protocol functions. Not every class that satisfies the
>> protocol will be implementing the interface directly, and so dot-
On 12 June 2012 14:28, Jim - FooBar(); wrote:
> Of course, I Just noticed that type-hinting 'p' renders the precondition
> useless...an extra performance bonus!
Not really -- only primitive type hints actually prevent the function
from accepting a non-matching argument:
(defn foo [^java.util.Map
The dot firm is an explicit call to interop. Protocols are a clojure concept :)
The underlying mechanism happens to look like a Java interface today.
However you can expect to bypass some niceties by doing this.
This is what the JVM offers today to implementors. Might be different in
future releas
On 12/06/12 19:41, Alan Malloy wrote:
It's not just less convenient, but genuinely incorrect to use dot-
notation for protocol functions. Not every class that satisfies the
protocol will be implementing the interface directly, and so dot-
notation will fail on them. The interface generated by def
On 12/06/12 14:43, Tassilo Horn wrote:
"Jim - FooBar();" writes:
If update-position is a protocol function just call it without the
dot. Just like a normal function. Then any reflection will go away
and no type hint is needed.
WHAT??? Seriously??? I'll try it...
OMG! You were right Meikel...
On Jun 12, 5:56 am, "Jim - FooBar();" wrote:
> On 12/06/12 13:53, Jim - FooBar(); wrote:
>
> > On 12/06/12 13:47, Meikel Brandmeyer (kotarak) wrote:
> >> If update-position is a protocol function just call it without the
> >> dot. Just like a normal function. Then any reflection will go away
> >>
"Jim - FooBar();" writes:
>> And when you say you have reflection warnings, can it be that you call a
>> protocol method foo with (.foo o) [note the .-syntax]...
>
> I'm not sure what you mean...Of course I'm calling a protocol method with
> (.update-position p coords) - with the '.'
> How else c
"Jim - FooBar();" writes:
>>> If update-position is a protocol function just call it without the
>>> dot. Just like a normal function. Then any reflection will go away
>>> and no type hint is needed.
>>
>> WHAT??? Seriously??? I'll try it...
>
> OMG! You were right Meikel... I cannot believe this
"Jim - FooBar();" writes:
> No what i have in IPiece is 'updatePosition' so each piece knows how
> to update its position.
Ok.
>> And when you say you have reflection warnings, can it be that you call a
>> protocol method foo with (.foo o) [note the .-syntax]...
> I'msure you will understand if
On 12/06/12 13:53, Jim - FooBar(); wrote:
On 12/06/12 13:47, Meikel Brandmeyer (kotarak) wrote:
If update-position is a protocol function just call it without the
dot. Just like a normal function. Then any reflection will go away
and no type hint is needed.
WHAT??? Seriously??? I'll try it...
On 12/06/12 13:47, Meikel Brandmeyer (kotarak) wrote:
If update-position is a protocol function just call it without the
dot. Just like a normal function. Then any reflection will go away and
no type hint is needed.
WHAT??? Seriously??? I'll try it...
Jim
--
You received this message because
Hi,
Am Dienstag, 12. Juni 2012 14:28:21 UTC+2 schrieb Jim foo.bar:
>
> Of course, I Just noticed that type-hinting 'p' renders the precondition
> useless...an extra performance bonus!
>
>
If update-position is a protocol function just call it without the dot.
Just like a normal function. Then a
And when you say you have reflection warnings, can it be that you call a
protocol method foo with (.foo o) [note the .-syntax]...
I'm not sure what you mean...Of course I'm calling a protocol method
with (.update-position p coords) - with the '.'
How else can I call it?
Jim
On 12/06/12 13:28
Of course, I Just noticed that type-hinting 'p' renders the precondition
useless...an extra performance bonus!
Jim
On 12/06/12 13:26, Jim - FooBar(); wrote:
On 12/06/12 13:16, Tassilo Horn wrote:
I don't get you. If IPieces can be moved, then move should be a
protocol method declared in IPie
On 12/06/12 13:16, Tassilo Horn wrote:
I don't get you. If IPieces can be moved, then move should be a
protocol method declared in IPiece.
No what i have in IPiece is 'updatePosition' so each piece knows how to
update its position. THere is more to a move though. 'move' is a regular
function
"Jim - FooBar();" writes:
Hi Jim,
> however I only want to do this to avoid a specific reflection
> call... you see my move function take either any type that satisfies
> IPiece and so at each call reflection is needed to decide which one to
> use...
I don't get you. If IPieces can be moved, t
Thanks Tassilo,
your suggestion of fully qualifying the protocol worked like a charm! I
managed to eliminate my last 2 reflective calls on the whole
namespace... this is good stuff!
Jim
On 12/06/12 12:57, Jim - FooBar(); wrote:
aaa ok I see...
however I only want to do this to avoid a spe
aaa ok I see...
however I only want to do this to avoid a specific reflection call...you
see my move function take either any type that satisfies IPiece and so
at each call reflection is needed to decide which one to use...I'd like
to say in the argument that what is coming is a IPiece so stop
"Jim - FooBar();" writes:
> why can't I use the interface as function argument instead of the
> concrete class (record)?
>
> example: (defprotocol IPiece
> blah blah blah)
>
> (defrecord ChessPiece
> IPiece
> blah blah blah)
>
> (defrecord CheckersPiece
> IPiece
> blah blah
why can't I use the interface as function argument instead of the
concrete class (record)?
example: (defprotocol IPiece
blah blah blah)
(defrecord ChessPiece
IPiece
blah blah blah)
(defrecord CheckersPiece
IPiece
blah blah blah)
(defn move [^IPiece p] ;will complain th
43 matches
Mail list logo
