On Mon, 29 Apr 2019 at 22:38, Guillermo Polito
wrote:
> A class is abstract by design and not necessarily because I can compute
> something from its implementation that tells me that maybe it is abstract.
> I somehow mark a class as abstract because it is abstract, not the other
> way around.
>
Hi Andrei, Doru,
Sorry for the late reply, I've been away on vacations last week :).
Denis introduced originally the behaviour making classes return true for
#isAbstract only when they had #subclassResponsibility methods in them.
Originally, if I'm not mistaken, it was to introduce the `should
Hi,
I think that it is good that isAbstract does not mean isInstantiatable.
However, I also think that isAbstract is too generic and that it would be
better to have the tools implement their meaning rather than relying on a
generic term.
Cheers,
Doru
> On Apr 23, 2019, at 5:58 PM, Andrei
I ended up being surprised today that classes that have abstract
methods (send #subclassResponsibility) were returning false to
`isAbstract` and true to `hasAbstractMethods`.
I see that the behavior for isAbstract changed over the years: when it
was added [1] it was checking for abstract methods.
I guess I could have added additional constraints
"and the missing method is called from a method on the "abstract class", and
the missing method is defined on subclasses", but I thought that implicit
from the context :)
To me, an abstract class is one you either can't instatiate (through
This is a use case that is addressed at the level of the method, not of a class.
I see the issue similarly to Stef: as I can utilize a class, it has little
meaning to call it abstract. A missing method has a different meaning from the
typical meaning associated with a class being abstract.
Tim Mackinnon wrote
> 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
Or, if the class has subclasses, one could get a suggestion/action to
implement the missing
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
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
> 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.
> BTW do we
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
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 plan new class definition in Pharo 8?
сб, 30 мар. 2019 г. в 18:35, Denis
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 includes: #isReallyAbstract) not or: [
> self isReallyAbstract ] ]
I also find that the last one resonates with what I would expect - and a real
class autocompletes easily too.
I also wonder if a class with subclasses should be considered abstract unless
specifically marked otherwise (but we need a simple way of doing this if we can
think of one - which isn’t
Le 30/03/2019 à 19:35, Denis Kudriashov a écrit :
> Hello.
>
> We did recently several cleanups by marking abstract classes as abstract
> using #isAbstract method
> (https://github.com/pharo-project/pharo/pull/3087,
> https://github.com/pharo-ide/Calypso/pull/462)
> .
>
> I would like to
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 includes: #isReallyAbstract) not or:
[
self isReallyAbstract ] ]
Hello.
We did recently several cleanups by marking abstract classes as abstract
using #isAbstract method (https://github.com/pharo-project/pharo/pull/3087,
https://github.com/pharo-ide/Calypso/pull/462) .
I would like to discuss here and decide what the right way to implement
this method.
The
19 matches
Mail list logo
