30288
-
11201 InvalidArgument + a few exceptions comments
https://pharo.fogbugz.com/f/cases/11201
11163 TestCase classrun convenience method
https://pharo.fogbugz.com/f/cases/11163
Diff information:
Hi,
in SmalltalkImagecheckAndOpenSourcesAndChanges, there is some code
that looks like this:
[...]
changes isReadOnly
ifTrue: [ self inform: 'Pharo cannot write to the
changes file ...' ].
[...]
This code raises a warning if the changes file can't be written to. In
the
On Jul 21, 2013, at 10:05 AM, Damien Cassou damien.cas...@gmail.com wrote:
Hi,
in SmalltalkImagecheckAndOpenSourcesAndChanges, there is some code
that looks like this:
[...]
changes isReadOnly
ifTrue: [ self inform: 'Pharo cannot write to the
changes file ...' ].
How about
SmalltalkImage checkChangesFileAvailability: false.
?
Norbert
Am 21.07.2013 um 10:04 schrieb Damien Cassou damien.cas...@gmail.com:
Hi,
in SmalltalkImagecheckAndOpenSourcesAndChanges, there is some code
that looks like this:
[...]
changes isReadOnly
On Jul 21, 2013, at 10:20 AM, Norbert Hartl norb...@hartl.name wrote:
Am 21.07.2013 um 10:16 schrieb Marcus Denker marcus.den...@inria.fr:
On Jul 21, 2013, at 10:05 AM, Damien Cassou damien.cas...@gmail.com wrote:
Hi,
in SmalltalkImagecheckAndOpenSourcesAndChanges, there is some
- transaction log attached to he end of the running image file
Ok, sounds reasonable on the one hand (getting rid of an additional file) and
dangerous on the other hand (on image write the transaction log needs to be
read/written/moved making it possible to loose image and transaction
May be we should refactor the code so that we can specify if the warning should
be raised
or not.
Hi,
in SmalltalkImagecheckAndOpenSourcesAndChanges, there is some code
that looks like this:
[…]
changes isReadOnly
ifTrue: [ self inform: 'Pharo cannot write to the
On 19 July 2013 19:14, Paul Davidowitz pdavi...@fastmail.fm wrote:
Igor - could you please explain 'the principle of least authority'?
Here the wiki link:
http://en.wikipedia.org/wiki/Principle_of_least_privilege
Thanks,
- Paul
--
Best regards,
Igor Stasenko.
On 20 July 2013 12:48, Denis Kudriashov dionisi...@gmail.com wrote:
Hi
2013/7/19 Igor Stasenko siguc...@gmail.com
So, on your place, if you really need a lot of classes with announcer
capabilities, you can do it like that:
Object subclass: #ObjectWithAnnouncer
instvars: 'announcer'
On 20 July 2013 21:31, Tudor Girba tu...@tudorgirba.com wrote:
Hi Igor,
Thanks for taking the time to write such a long answer.
I think you misunderstood my point :). I simply said that the two examples
are not the same (and I can add now that Butter subclass: #Fridge is as
bad as Shampoo
On Jul 21, 2013, at 2:38 PM, Igor Stasenko siguc...@gmail.com wrote:
Yes, but where are the guarantees that you don't?
Just think from outsider's point of view: when he sees
Announcer subclass: #Foo
what he will think first:
- aha, this guy implements own kind of announcer
or
- aha
Hi Igor.
2013/7/21 Igor Stasenko siguc...@gmail.com
There are 3 kinds of roles in context:
- subscriber: an object who subscribing for events to receive them later
- an event source (the object which announces the event)
- an announcer, an object which provides subscription service and
On Sun, Jul 21, 2013 at 12:10 PM, Stéphane Ducasse
stephane.duca...@inria.fr wrote:
May be we should refactor the code so that we can specify if the warning
should be raised
or not.
this happens at startup. Do you have an idea in mind? Should I add an
instance variable for that?
--
Damien
On Jul 21, 2013, at 5:36 PM, Denis Kudriashov dionisi...@gmail.com wrote:
2013/7/21 Igor Stasenko siguc...@gmail.com
Yes, but where are the guarantees that you don't?
Just think from outsider's point of view: when he sees
Announcer subclass: #Foo
what he will think first:
- aha, this
Though, Dictionary was technically a Set of Associations, until someone
changed Association= to also compare values.
2013/7/21 Stéphane Ducasse stephane.duca...@inria.fr
On Jul 21, 2013, at 5:36 PM, Denis Kudriashov dionisi...@gmail.com
wrote:
2013/7/21 Igor Stasenko siguc...@gmail.com
On Jul 21, 2013, at 7:30 PM, Nicolas Cellier
nicolas.cellier.aka.n...@gmail.com wrote:
Though, Dictionary was technically a Set of Associations,
yes but API(DICTIONARY) is not the same as API(SET) = ARGH
until someone changed Association= to also compare values.
subclassing
2013/7/21 Stéphane Ducasse stephane.duca...@inria.fr
Interesting how many people in this list think that Announcer subclass:
#TxEditor provides special implementation of announcer named TxEditor?
Many
this is composition using inheritance and inheritance should not be used
like that.
Of course, Dictionary was somehow a Set, but somehow behaved more like a
Bag (it could be seen as a Bag of values w.r.t. #do: behavior),.
But we still solved it with inheritance, just with an intermediate
HashedCollection capturing common abstract behavior...
2013/7/21 Stéphane Ducasse
And what I should do if I want Customer which can trigger events?
then ask yourself about the API of your customer
Do you want the full API of Announcer? I doubt.
Do you think EventSource subclass: #Customer make any difference? Or do
you think we should never use inheritance to make
2013/7/21 Stéphane Ducasse stephane.duca...@inria.fr
And what I should do if I want Customer which can trigger events?
then ask yourself about the API of your customer
Do you want the full API of Announcer? I doubt.
Do you think EventSource subclass: #Customer make any difference? Or
do
30289
-
11204 Crash if changes file is not writable
https://pharo.fogbugz.com/f/cases/11204
11198 Update Pharo with latest Opal
https://pharo.fogbugz.com/f/cases/11198
Diff information:
21 matches
Mail list logo
