data.xsl:26-29: This code tests for both org.eolang.TYPE...

[0pdd]

The puzzle 1104-f29eb2d4 from #1104 has to be resolved:

eo/eo-maven-plugin/src/main/resources/org/eolang/maven/pre/data.xsl

Lines 26 to 29 in 3113808

	@todo #1104:30m This code tests for both org.eolang.TYPE and TYPE.
	This is unnecessary. Investigate why add-default-package.xsl
	is not always called from eo-maven-plugin and use
	only qualified object names.

The puzzle was created by @rultor on 29-Aug-22.

Estimate: 30 minutes, role: DEV.

If you have any technical questions, don't ask me, submit new tickets instead. The task will be "done" when the problem is fixed and the text of the puzzle is removed from the source code. Here is more about PDD and about me.

[yegor256]

@mximp please, help us resolve this

[mximp]

@OlesiaSub could you please have a look

[OlesiaSub]

I have an explanation but I don't have a good solution yet.
@yegor256 @mximp please have a look.

Let's take a look at this piece of code located in your bool.eo file

# NOT
[] > not
  eq. > @
    ^
    FALSE

We are particularly interested in usage of FALSE.
In transpiled .xmir FALSE will look like this:

<o base="bool" data="bytes" line="43" pos="6" ref="29">00</o>

Note that it has a ref attribute because it's abstract object bool is located in the same file (bool.eo).
But add-default-package.xsl reasonably does not add default packages to the objects with ref attributes, so in all cases like this default package won't be added.

Same situation occurs when we use numbers representing int in int.eo file, etc. It does not occur in any other cases, so maybe removing this TYPE checks is not necessary?

[mximp]

@yegor256 @OlesiaSub This corresponds to the the description in add-default-package.xsl:

  <!--
  Here we go through all objects that DON'T have @ref attributes
  and add default package to them.

  We ignore objects that are present in aliases with their exact
  names. For example, this object 'hello' won't be touched, we
  won't think that it belongs to org.eolang package:

  +alias hello
  [] > app
    hello > @
  -->

So it looks like current behaviour is in line with common logic.
I can't think of any solution for fixing it rather than hardcode specific logic for data types in add-default-package.xsl, but I don't think it's worth to do.
I suggest to keep it as is.

[OlesiaSub]

@mximp yes, that's what meant. And I have the same opinion about it, I'd rather keep it

[mximp]

@yegor256 Can we remove the puzzle and close it as "won't fix"?

[yegor256]

@mximp sure, we just need to submit a pull request that removes the puzzle

[mximp]

@OlesiaSub please do

[0pdd]

The puzzle 1104-f29eb2d4 has disappeared from the source code, that's why I closed this issue.