cfml

Here's a stupid one I came across today: <https://trycf.com/gist/7634b8f9fa03a5069ad5ab713501ac29/lucee5?theme=monokai>

```a = [1,2,3]

a.each((cookie) =&gt; {
    writeDump(cookie)
})```
I've used a dumb variable name there (in the actual code I was looking over cookie values, so it made more sense :wink:), but still.. I would expect `1,2,3` (and that's what I get on CF), but on Lucee I get three dumps of the cookie scope.

I *think* CF's behaviour is legit... my own variable should take precedence over inbuilt ones (even if they "hide" the inbuilt ones).

It was an edge case though and easily solved. Still... it's a CF incompat so should probably be addressed?

Oh actually it's probably this: <https://luceeserver.atlassian.net/browse/LDEV-3647>. Fixed in 6 apparently

I'm surprised Lucee let you name that variable as `cookie`

if you change the dump to arguments.cookie it behaves like acf

Yeah, Lucee will never look for a scope name inside another scope if I recall.  Meaning, if you have `url.foo`, it will never scope hunt for `variables.url.foo` etc, it will just take it directly.  Adobe is more lax about allowing you to have `variables.url` or `variables.cookie`.  I think this is a documented compat for security or performance or whatever.

See the last paragraph on this page
<https://docs.lucee.org/guides/developing-with-lucee-server/reserved-word.html>

```In Lucee Server Scopes are always invoked first, which means all scope names, e.g. variables, url, form, session, application... are effectively reserved words. Lucee resolves scopes before a variable with the same name, so they can't be referenced/reached.```

Which includes this code sample
```application = 1;
dump( application ); // returns the application struct (not 1)```

So I don't think it's actually related to LDEV-3647, I think it's just one of those documented differences where Lucee is a bit more strict.

If scopes are reserved words, then it should give me an exception if I try to _use_ the "reserved word". That's kinda what it means.

But hey ho... [shrug]

Agreed, it's deceiving to allow you to create `arguments.cookie` but then not do any scoping hunting on it.  _That_ part I'm unclear if it's be design or just an accident.

technically, `arguments.cookie` works, but it's a bit of a pothole for you to step in.

Adobe's behavior is a bit crap as it sort of makes it impossible for you to access the _actual_ `cookie` scope inside your UDF it would appear.

I think CF's behaviour is fine. If I want to have an arg (or a local) called `cookie` - which I *did*, let's face it - then that should be my call. I'm a grown-up and I know the ramifications of it.

I'd really prefer all this global shit (various scopes) not even be accessible beyond top-level .cfm files at all. But I'm 20yrs too late for that suggestion :wink: