On Mon, Mar 9, 2015 at 12:54 PM, Serhiy Storchaka <storch...@gmail.com> wrote:
> On 09.03.15 17:48, Neil Girdhar wrote: > >> So you agree that the ideal solution is composition, but you prefer >> inheritance in order to not break code? >> > > Yes, I agree. There is two advantages in the inheritance: larger backward > compatibility and simpler implementation. > > Inheritance might be more backwards compatible, but I believe that you should check how much code is genuine not restricted to the idealized flags interface. It's not worth talking about "simpler implementation" since the two solutions differ by only a couple dozen lines. On the other hand, composition is better design. It prevents you from making mistakes like adding to flags and having carries, or using flags in an unintended way. > Then,I think the big question >> is how much code would actually break if you presented the ideal >> interface. I imagine that 99% of the code using flags only uses __or__ >> to compose and __and__, __invert__ to erase flags. >> > > I don't know and don't want to guess. Let just follow the way of bool and > IntEnum. When users will be encouraged to use IntEnum and IntFlags instead > of plain ints we could consider the idea of dropping inheritance of bool, > IntEnum and IntFlags from int. This is not near future. I think it's the other way around. You should typically start with the modest interface and add methods as you need. If you start with full blown inheritance, you will find it only increasingly more difficult to remove methods in changing your solution. Using inheritance instead of composition is one of the most common errors in objected oriented programming, and I get the impression from your other paragraph that you're seduced by the slightly shorter code. I don't think it's worth giving in to that without proof that composition will actually break a significant amount of code. Regarding IntEnum — that should inherit from int since they are truly just integer constants. It's too late for bool; that ship has sailed unfortunately. > > > > Here's another reason. What if someone wants to use an IntFlags >> object, >> > but wants to use a fixed width type for storage, say numpy.int32? >> Why >> > shouldn't they be able to do that? By using composition, you can >> easily >> > provide such an option. >> You can design abstract interface Flags that can be combined with >> int or other type. But why you want to use numpy.int32 as storage? >> This doesn't save much memory, because with composition the IntFlags >> class weighs more than int subclass. >> Maybe you're storing a bunch of flags in a numpy array having dtype >> np.int32? It's contrived, I agree. >> > > I afraid that composition will not help you with this. Can numpy array > pack int-like objects into fixed-width integer array and then restore > original type on unboxing? You're right. > > > > _______________________________________________ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: https://mail.python.org/mailman/options/python-dev/ > mistersheik%40gmail.com >
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
