why do we need bytes.as-string, .as-number, .as-i64, etc.?

[yegor256]

Why do we need bytes.as-string if we can simply use string? The same question for all others: they exist in bytes, but their functionality belongs to other objects, like number, i64, etc. I suggest deleting these methods.

[yegor256]

@maxonfjvipon WDYT?

[maxonfjvipon]

@yegor256 the method bytes.as-number provides all necessary checks before actual converting so not all bytes can be converted. I think we should not delete them

[yegor256]

@maxonfjvipon can't we have these checks inside the number object?

[maxonfjvipon]

@yegor256 no, it leads to infinite recursion:

[as-bytes] > number
  if. > @
    as-bytes.size.eq 8 # here new number is created and the check is started again
    good
    error
  ...

I tried to implement it when I was introducing i64 and I was failed

[maxonfjvipon]

@yegor256 also there's no way we can create nan or infinites from bytes using just application

[yegor256]

@maxonfjvipon how about this instead:

[as-bytes] > number
  if. > @
    as-bytes.size.eq
      40-20-00-00-00-00-00-00           # this is "8"
    good
    error
  ...

[maxonfjvipon]

@yegor256 here when we take as-bytes.size - the new number is created again, so it's recursion anyway

[yegor256]

@maxonfjvipon maybe we can get rid of error checking and accept anything as an argument of number?

[maxonfjvipon]

@yegor256 it's how we do it right now. But someone should validate at least something. I think it's not a really good idea to put all this validation to the end user shoulders. So if we have bytes as input and want to convert them to number - we let bytes decide if such converting is possible and what number should it be in the end - regular, nan or infinite.
Also I don't really understand what's the problem of having such converters? They're safe and quite convenient

[yegor256]

@maxonfjvipon the key problem is a duplication of functionality. Now I can do both (and I don't know which way is preferable):

# first:
string
  42-43-44

# second:
42-43-44.as-string

The presence of such a duality is an indicator of a design flaw, in the language (or SDK), I believe.

[maxonfjvipon]

@yegor256 maybe we can do the next:

[as-bytes] > number
  if. > @
    as-bytes.size.eq ... # 8 as bytes here
    unsafe as-bytes
    error ...
  [as-bytes] > unsafe
    ... # all number attributes here

Since bytes.size is an atom we can create org.eolang.number.unsafe directly in Data.ToPhi. WDYT?

[yegor256]

@maxonfjvipon looks like a good solution