>> I argue that we're not actually adding any complexity: yes, we add >> a class (per protocol), but we then merely relocate functionality to >> clarify the intended use of the classes. > >And I argue the moving this functionality to new classes (and adding >new restrictions to existing classes) doesn't buy anything in the way >of overall functionality of the module or a developer's ability to >comprehend intended uses.
It's mostly just minor refactoring and renaming, which I think makes things clearer, although I agree this is merely an opinion. I would be interest to hear what others think. To summarise: * an address is a singleton (a network endpoint), with no container behaviour. It may optionally reference it's network (via the .network attribute), .address returns mask-less address. * a network is a container-like object. For consistency, .network should return self and raise an exception if the mask conflicts with the address, .address returns the base address, .mask returns an address object. >> I would argue that a Network never has a single address - by definition, >> it has two or more nodes. A .network attribute should return a Network >> instance. If you want the base address, this probably should be called >> .base_address or just .address (to parallel the .netmask attribute). > >.network is shorthand for network address. are .network_address and >.broadcast_address less confusing? I have to say, though, >.network/.broadcast are fairly common (IPy uses .net, netaddr and ipv4 >use, IIRC .network...) Yes, I understand your motivation, but I still think it's going to be more confusing the way you have it. >> This isn't about shortcuts, but about correctness... having the Network >> object represent a network, and having Address objects represent >> end-points, and having errors discovered as early as possible. > >Then what I don't see is the purpose of your >network-only-network-object. essentially identical functionality can >be obtained with the module as is w/o the added complexity of new >classes. Certainly, I'm not talking about adding functionality. What I am suggesting is that if we wish to have a distinction between networks and addresses, then that distinction should be clear and strong, such that the choice of which to use is obvious, and if the wrong one is used, the error is discovered as early as possible. As the module stands, we have a pair of address-without-mask classes called *Address, and a pair of address-with-mask classes called *Network. So, sometimes when you want to record an *address* you use a class called Network, and that class comes with a behaviours that make no sense in the context of a singleton network end-point (it can't "contain" other addresses, although it's .network can). Sorry if I sound like a cracked record - these are subtle concepts, and my ability to explain what I mean is less than is needed, but we'll get there in the end. -- Andrew McNamara, Senior Developer, Object Craft http://www.object-craft.com.au/ _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
