I’d say custom tag for that. Or just not allow it, because if you needed
it, you’re doing it wrong. Don’t do it wrong.
thats just like, your opinion man.
Well… duh, Ryan. Of course it bloody is.
And I think its important to point this out because there are some people
who take what you say as having weight and authority here.
Well they’re bloody idiots then, TBH. And given that, then perhaps just
doing what I say is perhaps better for them in the long run anyhow.
That said… I stand by what my opinion happens to be at the given point in
time it as offered as being my best analysis of the situation, and
accordingly my best advice. I seldom type stuff in for shits ‘n’ giggles.
I do reserve the right to change my opinion when presented with better
information, though.
Please remember that there are people who need to write simple scripts,
not applications - and that may mean a one page chunk of logic and view.
Please, in general, remember that there are people who have needs and
tastes that don’t match your own.
Right. So don’t use a templating engine for that. Whenever a templating
engine is in place, one can still just emit a string instead. No-one’s
forcing anyone to a framework (or a design pattern) for writing a simple
script.
However the bulk of code written in CFML is not for simple scripts, it’s
not even for simple websites. It’s for medium-to-complex websites (erring
on the medium end of the scale, sure). And code written for that kind of
requirement should be written “properly” (I don’t think anyone here
seriously disagrees with that?)
I’m not against supporting other template engines, especially if it makes
someone coming from other languages more comfortable, but I don’t see any
point in getting rid of pound signs and cfml just because you think its old
and crufty.
For fuck’s fucking sake.
No-one is suggesting changing CFML one jot.
Jesus.
At no point has anyone suggested doing anything to Lucee’s CFML support
other than continuing it.
Give people options, don’t restrict based on some high-horse idea of right
and wrong. Lets extend the language, give new options. Make the case why
the new way is the best way and let developers convert as they are
convinced, not take away their toys and tell them they’re playing with them
wrong.
I would still argue […]
Well you’re not arguing, you’re just missing the point.
I’d like to also propose that for large feature proposals like this that
we take a page from JS, Python, Java and other languages and actually put
forward actual formal proposals. Here is an example from python:
https://www.python.org/dev/peps/pep-0255/, or another from JS:
GitHub - tc39/proposal-Array.prototype.includes: Spec, tests, reference implementation, and docs for ESnext-track Array.prototype.includes This would allow us to
discuss and refine ideas, allow the lucee team to accept proposals but say
that certain parts need tweeks or more thought. It would also make it clear
to outsiders exactly what status a given proposal is in, and if it has the
approval of the team or not. I would argue both the google group and the
bitbucket issues are not ideal places for conversations like these, unless
it is a simple new function or tweak. I don’t know all the answers on how
to do it, but want to throw it out there for considerations.
Yep, a very good suggestion. I think we’re a wee ways off needing that
sort of thing yet? I think the formal document should come after the
initial general discussion. If we get some sort of accord on a given idea,
then someone can draft up a formal proposal.
That said, I’ll chat on a forum on stuff until the cows come home, but I’m
buggered if I’d ever draft a formal proposal. Does that make me a bad
person?
My 2 cents.
Stop diluting the merits of your contribution. Even if I don’t agree with
it ;-)On Saturday, 7 February 2015 20:56:05 UTC, Ryan Guill wrote:
–
Adam