4 ms·

Don't you think it's a ridiculous notion that the distinctions between include and require (and the once variants) are meaningful enough that programmers should

Don't you think it's a ridiculous notion that the distinctions between include and require (and the once variants) are meaningful enough that programmers should be able to express them? Not at all. They mean different things, and they're used for different things. Import-if-it's-available is include, import-or-error-if-missing is require, and they're both quite handy. The once variants do what most programmers would expect, but the non-once ones do what most template users would expect. Should the "once" have been a flag? Yeah, why not? But that doesn't mean the functionality shouldn't even exist.

jessedhillon 15y ago
The `once` distinction is a product of bad design and it only exists when you have a language that is both the templating (view) language and the processing language. To those of us accustomed to good languages, it's like saying "the language allows me to call render_once() so that I don't re-render a template I've already rendered." When the problem is framed thus, most people would recognize that the solution to that problem is a better understanding on the part of the programmer of the flow of control inside his/her application. The error handing should be done with exceptions. As it is, there are many errors in PHP which are recoverable, but they don't throw exceptions but instead emit other kinds of non-catchable failures. In Python, you would simply `try` to import a module and `catch` a failure to do so, e.g. if that module wasn't installed.
- wvenable 15y ago
  > The `once` distinction is a product of bad design and it only exists when you have a language that is both the templating (view) language and the processing language. PHP takes it's cues from C -- that's where the idea of include() and require() come from. These functions pre-date the existence of OOP in PHP. There was a time when even the _once() functions didn't exist and you had to manage that yourself. It's best to think of these functions as low-level building blocks you can use to build on your own abstraction layer. I never call those functions directly. > The error handing should be done with exceptions. PHP supports many styles of development. If you prefer errors, you can have those. If you prefer exceptions, you can convert all errors to exceptions with only a few lines of code (there is even a built in exception type for this purpose).
- randallsquared 15y ago
  To those of us accustomed to good languages, it's like saying "the language allows me to call render_once() so that I don't re-render a template I've already rendered." Right, and there's a case for that in languages that need a template library, as well. In some cases, you want to re-render a template for some other place in the output, and in other cases, you'd want to use a previously cached rendered template, and both of those cases are useful. So, I agree that the distinction between the cases is the result of PHP being both a full programming language and a built-in templating language. I don't view this (in and of itself) as a bad thing, though I would quibble with the exact implementation, which is how it is for historical reasons. When the problem is framed thus, most people would recognize that the solution to that problem is a better understanding on the part of the programmer of the flow of control inside his/her application. Since you've already agreed that having the option for rerendering is a feature of including templating as a core feature, it seems like this statement is equivalent to declaring that templating should never be a core feature of a programming language. It's less about the flow of control and more about whether the result is cached. Even programmers who have a good understand of their programs' flow of control occasionally find memoization useful. :)
  - jessedhillon 15y ago
    *_once doesn't memoize, however. The result of include_once called twice isn't that the same template is repeated, but rather that the first call outputs the template and the second call is silent. include/require_once are not statements to the effect of "return same output as the last time I include/required this" but rather "if I haven't already include/required this, do it now." It's a very difficult proposition to say that good programming requires the latter capability.
    - randallsquared 15y ago
      Uh, that's what import in Python does. It doesn't reimport; it ignores the import request if you've already done it, right? (I must confess I haven't used Python a lot in the last few years, but it used to be my primary language). So, if you're willing to accept my assertion that Python is a good programming language, then you'll have to agree that that latter capability is the default in at least some good programming languages. The former capability to which you refer, though, is quite often useful for including template fragments, so I wouldn't want to throw it out, either. If you said, "Hey, these only seem conceptually similar because of the name, and they're really different things", I'd be willing to go with that, I think. Or, if you were to say, "Hey, these are so similar that we shouldn't have a whole separate name for the behavior switch", I'd agree with that, as it's my position. However, it seems as though you're arguing that one of the two behaviors is never needed in a good web application domain language, and I disagree with that.

jessedhillon 15y ago

The `once` distinction is a product of bad design and it only exists when you have a language that is both the templating (view) language and the processing language. To those of us accustomed to good languages, it's like saying "the language allows me to call render_once() so that I don't re-render a template I've already rendered." When the problem is framed thus, most people would recognize that the solution to that problem is a better understanding on the part of the programmer of the flow of control inside his/her application. The error handing should be done with exceptions. As it is, there are many errors in PHP which are recoverable, but they don't throw exceptions but instead emit other kinds of non-catchable failures. In Python, you would simply `try` to import a module and `catch` a failure to do so, e.g. if that module wasn't installed.

wvenable 15y ago
> The `once` distinction is a product of bad design and it only exists when you have a language that is both the templating (view) language and the processing language. PHP takes it's cues from C -- that's where the idea of include() and require() come from. These functions pre-date the existence of OOP in PHP. There was a time when even the _once() functions didn't exist and you had to manage that yourself. It's best to think of these functions as low-level building blocks you can use to build on your own abstraction layer. I never call those functions directly. > The error handing should be done with exceptions. PHP supports many styles of development. If you prefer errors, you can have those. If you prefer exceptions, you can convert all errors to exceptions with only a few lines of code (there is even a built in exception type for this purpose).
randallsquared 15y ago
To those of us accustomed to good languages, it's like saying "the language allows me to call render_once() so that I don't re-render a template I've already rendered." Right, and there's a case for that in languages that need a template library, as well. In some cases, you want to re-render a template for some other place in the output, and in other cases, you'd want to use a previously cached rendered template, and both of those cases are useful. So, I agree that the distinction between the cases is the result of PHP being both a full programming language and a built-in templating language. I don't view this (in and of itself) as a bad thing, though I would quibble with the exact implementation, which is how it is for historical reasons. When the problem is framed thus, most people would recognize that the solution to that problem is a better understanding on the part of the programmer of the flow of control inside his/her application. Since you've already agreed that having the option for rerendering is a feature of including templating as a core feature, it seems like this statement is equivalent to declaring that templating should never be a core feature of a programming language. It's less about the flow of control and more about whether the result is cached. Even programmers who have a good understand of their programs' flow of control occasionally find memoization useful. :)
- jessedhillon 15y ago
  *_once doesn't memoize, however. The result of include_once called twice isn't that the same template is repeated, but rather that the first call outputs the template and the second call is silent. include/require_once are not statements to the effect of "return same output as the last time I include/required this" but rather "if I haven't already include/required this, do it now." It's a very difficult proposition to say that good programming requires the latter capability.
  - randallsquared 15y ago
    Uh, that's what import in Python does. It doesn't reimport; it ignores the import request if you've already done it, right? (I must confess I haven't used Python a lot in the last few years, but it used to be my primary language). So, if you're willing to accept my assertion that Python is a good programming language, then you'll have to agree that that latter capability is the default in at least some good programming languages. The former capability to which you refer, though, is quite often useful for including template fragments, so I wouldn't want to throw it out, either. If you said, "Hey, these only seem conceptually similar because of the name, and they're really different things", I'd be willing to go with that, I think. Or, if you were to say, "Hey, these are so similar that we shouldn't have a whole separate name for the behavior switch", I'd agree with that, as it's my position. However, it seems as though you're arguing that one of the two behaviors is never needed in a good web application domain language, and I disagree with that.