Add Text.write Function

[radeusgd]

Pull Request Description

Implements https://www.pivotaltracker.com/story/show/182309026

Important Notes

Checklist

Please include the following checklist in your PR:

• The documentation has been updated if necessary.
• All code conforms to the
  Scala,
  Java,
  and
  Rust
  style guides.
• All code has been tested:
  • Unit tests have been written where possible.
  • If GUI codebase was changed: Enso GUI was tested when built using BOTH
    ./run ide dist and ./run ide watch.

[JaroslavTulach]

Importing something from Standard.Base.System.File seems to create a direct link from core strata of the language (as Text is one of the core types) towards much less important strata - e.g. I/O subsystem. I believe this goes against principles of modularity. I believe the language and core libraries shall be as small as possible, but modularly extensible - be it Java or Enso.

This decay of mutual dependencies between different stratas of StdLib is hard to prevent, when we don't have tools to ensure compile time failures when a core strata attempts to call higher level strata. However that doesn't mean we should encourage such dependencies. Having reference to File in Text.enso is an example of such strata crossing dependency and I'd suggest to avoid it.

I know where it leads (see The Entropy of Software page 60, Practical API Design Confessions of a Java Framework Architect book). I've been there at least twice. With NetBeans and with Java. We end up with (this time not object but) functionally oriented spaghetti code and it is going to be hard to fix the mutual dependencies in future.

I guess the primary motivation for having Text.write is usability. Our users are more likely to find the method on existing Text object than some static function in some other library. Such a desire goes against the modularization effort. Huge problem when designing Java APIs, but other modern languages have an answer to that: extension functions.

Doesn't Enso also supports extending other types with new functions/methods? Then the write function should be defined by File.enso, but register itself as an extension into Text type.

If possible, I'd find it way better design from modularity perspective.

[hubertp]

I'm kind of inclined to agree that we are heading towards a spaghetti monster but at the same time PR implements what the ticket asked for

[radeusgd]

I'm happy to move it to File if we decide that's the right approach.

Reg. extension functions - we have those yes, so I can rely on it. But I'm not sure if the language spec 1.0 includes them - IIRC they are removed so the situation may complicate a bit. Maybe we will be able to emulate the desired behaviour with a typeclass.

So I can move the definition to File.enso - question is - depending on the language spec, if we may need to move it back here. But since this is a small operation, I think it is ok to do so.

[wdanilo]

@JaroslavTulach That's a very good argument. Our stdlib is a little bit spaghetti because of lack of refactoring (which should be done in the meantime when implementing tasks) and also because of lack of proper tools to resolve it. It was one of the reasons why we are making changes to the language design. Currently, you don't have the tools in the language to resolve SOME of such a convoluted designs. In the past, we were thinking that we can introduce type classes to the language later in the future, but we realized that lack of them is very harmful right now - your comment shows one of such harmful behaviors The new lang design allows for making it nicer. We will fix the lang and then fix the libraries. On Monday the doc will be ready for reading, I'll ping you guys and I'd love to hear feedback about it from the perspective of this issue.

[jdunkerley]

We've implemented it as an extension within File.enso. Once we have the design doc agreed we should do a sanity pass and make sure all is how we want it.

[hubertp]

I would probably favour File.wrtie_text text instead of Text.write file as well

[hubertp]

This would probably benefit from #3471 which is the final stages of being merged

[jdunkerley]

We discussed File.write_text as part of the design process. It was felt more natural to flow to be working with the object we want to write to a file.

I think we may find we want to add File.write_text at some point later but this will be easier to judge once we have a more feature complete GUI.

[JaroslavTulach]

Thank you. Defining Text.write in File.enso looks way nicer from an architecture perspective.