Could I get some clarity on Lucee's documentation's usage of the notion of "Unimplemented"? Ref: https://docs.lucee.org/reference/tags/log.html This claims the

file

attribute is "Unimplemented", yet... seems to work to me. I am worried that "Unimplemented" used in conjunction with Lucee's idiosyncratic understanding of "deprecated" might mean that all bets are off when it comes to those attributes persisting in the future.

Of no help but I was equally confused by the same page also writelog does not mention debug as a type but

How the hell is one supposed to log wibbles?!

you start with a pencil in each nostril

My loggers don’t wibble wibble, it folds…

i cant prove it with an error but...

might mean that all bets are off when it comes to those attributes persisting in the future.

yeah nah, we aren't going to be removing anything, backwards compatibity is important to use. If it's implemented, and if you really care about it then perhaps file PR which updates the tag/function defintion and with test coverage?

backwards compatibity is important to use

It's utterly bewildering that you pepper "deprecated" all over the place then. But anyway. You don't really explain why it's marked as "Unimplemented". Is this a misunderstanding of this term? Or just... wrong? Ain't writing yer tests for you: whoever did the implementation shoulda done that. And they should be made to go back and backfill them now. However I will put a PR in for the docs if you clarify that "unimplemented" is just wrong. Also perhaps removing "deprecated" because clearly it isn't. It's there, it works, and it needs to work because removing it would break compat with CF for one thing. It's just wrong-headed and unhelpful to suggest it's deprecated.

not in the docs, in Lucee core, which the docs automatically extracted from it's metadata, you can't edit in docs , it's from the .fld / .tlds https://github.com/lucee/Lucee/search?q=%3Cstatus%3Eunimplemented%3C%2Fstatus%3E I have no idea why they are flagged as unimplemented, you've been involved in Lucee longer than me, some of this code is over 15 years old

you've been involved in Lucee longer than me, some of this code is over 15 years old

Well yes. However I'm not really after a history lesson or how things came to be how they are. Right here, in July 2022, I'm just trying to get clarification as to whether I should read anything into a situation where the docs say something is unimplemented when it seems like it is implemented. Asked this or a variation on it a few times now. Thusfar I've not had an on-point answer.

i think it's great you are concerned about this

I think you misunderstand: I'm not really that concerned, I'm just raising a potential shortfall / inaccuracy in the docs, and trying to clarify what they should say. Am I to take from all this that the answer to this question:

You don't really explain why it's marked as "Unimplemented". Is this a misunderstanding of this term? Or just... wrong?

is "yes, it's just wrong"? <----- this is all I'm really interested in.

@zackster had a quick look in https://github.com/lucee/Lucee/blob/5.3.9/core/src/main/java/resource/tld/core-base.tld the log entry in there does not match the docs the unimplemented attributes are not in the file and the secription of the text and exception attributes are reversed

<attribute>
			<type>string</type>
			<name>text</name>
			<required>false</required>
			<rtexprvalue>true</rtexprvalue>
			<description>an exception to log.</description>
		</attribute>
		<attribute>
			<type>any</type>
			<name>exception</name>
			<required>false</required>
			<rtexprvalue>true</rtexprvalue>
			<description>The message text to log.</description>
		</attribute>

@thisOldDave ta, I fixed the tld https://github.com/lucee/Lucee/commit/d6360c206602405b8e908017eee31c7b6148bbf8 docs are more up to date, we don't have a round tripping process in place (yet) the current rules definition drops anything without the implemented status into Unimplemented, with the actual status listed below the description https://github.com/lucee/lucee-docs/blob/master/builders/html/templates/function.cfm#L74

This is edging ever so close to getting an actual explicit answer to this:

is "yes, it's just wrong"? <----- this is all I'm really interested in.

I'm sure than in no more than a few days, we'll be there. --- In other news it seems odd that in the docs to something that one has to explicitly say "it's implemented" because the default behaviour is "no it's not". Exactly how much time does one spend documenting stuff that's not implemented, for that to be the most sensible default? [weird]

it more or less defaults to implemented if it's not specified

I must be misreading this code then:

<cfif local.arg.status neq "implemented">
    <cfset arrayAppend(unimplementedArgs, local.arg)>
	<cfcontinue>
</cfif>

Cos that does the exact opposite of what you said, doesn't it?

That's the very code you pointed us to to say how it is handled!

i said "more or less" coz I know it works and that's how it worked my mental modal, which turned out to be true