Frankly I found strange that we care about this because
we can still instantiate an abstract class
and I do not really see how annotating that a class is abstract help
us.
If I can instantiate an object and send messages and the class is
abstract but there is no
> On 30 Mar 2019, at 21:05, Denis Kudriashov wrote:
>
> We can also look into it from the other side. All these methods are
> definitely a kind of code duplication.
> I think what we need here is an explicit property for classes. It could be
> even part of class definition.
> BTW do we
Calypso warns you about missing methods if it doesn’t understand a class is
abstract, so it’s useful to avoid those warnings otherwise you become
desensitised to them.
Tim
Sent from my iPhone
> On 31 Mar 2019, at 22:06, ducasse wrote:
>
> Frankly I found strange that we care about this
Regarding "PharoLaunched Windows 32bits Pharo 8 image raises primitive
failed error"
because there seems to be no Pharo 8 32-bit Windows VM configured for
PharoLauncher
https://github.com/pharo-project/pharo/issues/3053
and considering...
* Mojave is Apple's last version of macOS to support
> Am 30.03.2019 um 21:05 schrieb Denis Kudriashov :
>
> We can also look into it from the other side. All these methods are
> definitely a kind of code duplication.
> I think what we need here is an explicit property for classes. It could be
> even part of class definition.
I use it myself
On 30 Mar 2019, at 21:05, Denis Kudriashov wrote:
We can also look into it from the other side. All these methods are
definitely a kind of code duplication.
I think what we need here is an explicit property for classes. It
could be
even part of class definition.
I'm not sure whether that's
On 30 Mar 2019, at 20:56, Denis Kudriashov wrote:
> Hi Max.
>
> сб, 30 мар. 2019 г. в 19:08, Max Leske :
>
>> Hi Denis,
>>
>> I'm not too happy with any of those. For my own applications I use the
>> following:
>>
>> isAbstract
>> ^ self subclasses notEmpty and: [
>> (self class localSelectors
