Hi,
i guess i can subsume almost everything i know about hashes in one sentence:
it is my understanding that two objects that are equal (obj1=obj2.
-->true) have to have the same hash value (which is used for some
collection types), whereas objects where obj1=obj2 returns false should
have differen
Just a quick guess seeing the implementation
hash for collections is about hash of its elements
SequencableCollection>>hasEqualElements: otherCollection
"Answer whether the receiver's size is the same as otherCollection's
size, and each of the receiver's elements equal the corresp
But it raises the question if :
(1 to:4)hash = #(1 2 3 4)hash should return true instead ??
Cedrick
> Le 30 juil. 2018 à 14:51, Cédrick Béler a écrit :
>
> Just a quick guess seeing the implementation
>
> hash for collections is about hash of its elements
>
> SequencableCollection>>hasEqualE
Werner,
I would say that you are right, this is a problem. A (not un-common) source of
subtle bugs in Smalltalk is missing this rule that equivalent objects must have
the same hash. In GemStone the objects are not equivalent (I’m not arguing that
this is right, just that it avoids the problem y
Hi,
is there some library or approach how to do transactions in pharo?
And I don't mean database transactions, but directly in memory on Pharo
objects... e.g.
p := Person new.
transaction do: [
p name: 'Nobody'.
p age: 70.
] on: Error do: [
transaction rollback.
].
self assert: p na
I think it is a tricky thing to do "in memory transactions", even
without thinking about databases.
You have to define what to keep and where to place the "original"
values (inst. vars.) of the object.
As a general purpose solution if you can do that, you end up
implementing a mini gemstone in Pha
Maybe you can have a look to this paper :
https://www.sciencedirect.com/science/article/pii/S1477842408000237
On Mon, Jul 30, 2018 at 2:17 PM Peter Uhnák wrote:
> Hi,
>
> is there some library or approach how to do transactions in pharo?
> And I don't mean database transactions, but directly in
Peter Uhnák wrote
> is there some library or approach how to do transactions… directly in
> memory on Pharo
> objects
Magritte? It uses the Memento pattern to verify all changes before
committing to real object.
-
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f13106
El lun., 30 jul. 2018 a las 11:03, Sean P. DeNigris
() escribió:
>
> Peter Uhnák wrote
> > is there some library or approach how to do transactions… directly in
> > memory on Pharo
> > objects
>
> Magritte? It uses the Memento pattern to verify all changes before
> committing to real object.
But y
jgfoster wrote
> Werner,
>
> I would say that you are right, this is a problem. A (not un-common)
> source of subtle bugs in Smalltalk is missing this rule that equivalent
> objects must have the same hash. In GemStone the objects are not
> equivalent (I’m not arguing that this is right, just that
Hi,
thank you all for your answers.
Cédrick Béler wrote:
> But it raises the question if :
> (1 to:4)hash = #(1 2 3 4)hash should return true instead ??
principally yes, but it would slow down the Interval>>hash
implementation considerably. id guess one would first make
SequentialCollection>>hash
The interval
1 to: (10 raisedTo: 100)
can be created just fine, yet hashing its elements won't compute.
A generous interpretation of the intent of #=, where any wisp of
equivalence is promoted to full fledged equality, is problematic in the
long run. Here's another one:
17/
Basically, what you are talking about is Software Transactional Memory.
According to
https://en.wikipedia.org/wiki/Software_transactional_memory#Smalltalk
there *is* STM support for Pharo at
http://source.lukas-renggli.ch/transactional/
although the last version there is from 2012, and there have b
Hi Andres,
that is the kind of argument i was looking for, as i thought i would
have a similar situation as in my small example and wondered whether i
could keep my slightly incongruent definition of #= and #hash, but in a
way your examples show that my problem is different, iow i should change
my
I do not think that (1 to: 4) and #(1 2 3 4) should be equal.
Let me put it a little more strongly: it's a bug.
Taking
a := 1 to: 4.
b := Array withAll: a.
c := OrderedCollection withAll: b.
in the two other Smalltalk systems I just tried,
no two of these are equal. This is what the ANSI
Sm
+1 to what Andreas Valloud (Mr "how to hash in Smalltalk") said.
On 31 July 2018 at 10:34, Andres Valloud
wrote:
> The interval
>
> 1 to: (10 raisedTo: 100)
>
> can be created just fine, yet hashing its elements won't compute.
>
> A generous interpretation of the intent of #=, where any
> Am 30.07.2018 um 15:16 schrieb Peter Uhnák :
>
> Hi,
>
> is there some library or approach how to do transactions in pharo?
> And I don't mean database transactions, but directly in memory on Pharo
> objects... e.g.
>
> p := Person new.
>
> transaction do: [
> p name: 'Nobody'.
> p
> Am 30.07.2018 um 16:02 schrieb Sean P. DeNigris :
>
> Peter Uhnák wrote
>> is there some library or approach how to do transactions… directly in
>> memory on Pharo
>> objects
>
> Magritte? It uses the Memento pattern to verify all changes before
> committing to real object.
>
This only work
> Am 31.07.2018 um 06:57 schrieb Richard O'Keefe :
>
> Basically, what you are talking about is Software Transactional Memory.
> According to
> https://en.wikipedia.org/wiki/Software_transactional_memory#Smalltalk
> there *is* STM support for Pharo at
> http://source.lukas-renggli.ch/transactio
19 matches
Mail list logo
