> On Jan 6, 2020, at 4:59 PM, Rowan Tommins <rowan.coll...@gmail.com> wrote:
> I'm still struggling to understand why you need multiple constants, all > mutable based on some other dimension. > If the ultimate goal is to know the name and branch of the *current* > environment, how do the constants help? At least two come to mind: 1. Guard clauses for code you only want to run in one environment and not another. 2. Common code that is used by different websites. > We'll just have to agree to disagree here. I stand by the assertion that > "compile-time constants" are a well-defined feature, whose restrictions are > part of their definition and purpose. > That method is not actually a feature of constants, its abusing the fact that > everything is an object, so the *value* of a constant might still be a > mutable object. It's an interesting "cheat", but it's not really a deliberate > language feature. The .replace is not a deliberate language feature? > Unless I'm missing something, this isn't really related to anything we've > been discussing, it just happens to use the keyword "const". It is not exactly the same, but it is used to create immutable values stored in variables, aka constants. Hence why I included. > Those links seem to say that Python doesn't have constants *at all*, but you > can emulate them in various ways. As such, you can give them pretty much > whatever behaviour you like, since you're defining the language feature from > scratch. Yes. IOW, Python did not feel there was a need for a compile-time constant. > The biggest sticking point in my mind is your insistence that they share > syntax with constants, rather than variables. This means they can only be > used in static class or namespace context, not against an instance. It's not an insistence per se, it is the use-case I am trying to address. I can already use static variables, and the immutability is not that important to me. It's the desire to be able to start as statically declared constants and evolve later to dynamically initialized. As for immutable variables, I see those as very useful to, but I think their use-cases are orthogonal to the use-case I was trying to address. > It also means *widening* the meaning of a construct, rather than *narrowing* > it: the "final" keyword in Java doesn't let variables do anything new, it > just restricts them; your proposed constant initialization would allow > constants to act in new ways, including holding complex, mutable types. But isn't that often the point of new features; to allow for doing things in new ways? > That's likely to cause confusion for both humans I often chuckle when I hear that something might cause confusion as an argument against adding to PHP because it makes me think of PHP generators, generator return expressions and Generator delegation! I assert that if we can add generators (and in the future, generics!) then most anything we could add is going to be less confusing. :-) > and tools written based on the current concept that a constant can always be > computed at compile-time. My assumption is that the tool would simply be updated to recognize which constants would be initialized at runtime. > The difference is that a Java-style "final variable" can have a single value > *per instance*, I cannot think of anything conceptual that would keep us from having constants per instance, but I don't see a strong need for is so I did not propose it. > I would be interested to hear more about why you think pre-processing doesn't > suit your use case. When I think of pre-processor, I think of textual substitution. It is very difficult if not impossible to write textual pre-processing code that is both reusable _and_ composible with pre-processing code that someone else wrote. Thus if there are several header files in the wild, you typically can only use one of them. I am still influenced by the words of Bertrand Meyer in the book where I first learned object oriented programming "Object Oriented Software construction" in his section on Composability: > "A method satisfies Modular Composability if it favors the production of > software elements which may then be freely combined with each other to > produce new systems, possibly in an environment quite different from the one > in which they were initially developed." > "Counter-example: preprocessors. A popular way to extend the facilities of > programming languages, and sometimes to correct some of their deficiencies, > is to use “preprocessors” that accept an extended syntax as input and map it > into the standard form of the language. Typical preprocessors for Fortran and > C support graphical primitives, extended control structures or database > operations. Usually, however, such extensions are not compatible; then you > cannot combine two of the preprocessors, leading to such dilemmas as whether > to use graphics or databases." From page 42: http://web.uettaxila.edu.pk/CMS/AUT2011/seSCbs/tutorial/Object%20Oriented%20Software%20Construction.pdf <http://web.uettaxila.edu.pk/CMS/AUT2011/seSCbs/tutorial/Object%20Oriented%20Software%20Construction.pdf> Finally, a long time ago in a far away galaxy I was a Clipper developer, and in version 5.0 they implemented a preprocessor to enable user-defined commands. Many of us including myself jumped on them and created some pretty horrific architectures, and then quickly found what a nightmare they are when trying to combine them. -Mike
