feat(#28): Add blog post about probing #29
Conversation
feat(objectionary#28): add .idea to gitignore feat(objectionary#28): Add the article about probing mechanism
_posts/2023/03/2023-03-13-probing.md
Outdated
| simply print the name of the object and that is all that is required. The | ||
| compiler will automatically locate all the requested objects through the | ||
| implementation of a new probing feature, which was recently added. In this short | ||
| blog, we will attempt to explain how this feature works. Let's take a look at |
There was a problem hiding this comment.
@volodya-lombrozo "short blog post"
There was a problem hiding this comment.
@mximp Done, thanks!
_posts/2023/03/2023-03-13-probing.md
Outdated
|
|
||
| As you can see from the code, the purpose of this program is to print the magic | ||
| number to the standard output. However, what is `org.eolang.io.stdout` and | ||
| `org.eolang.io.stdout` here? They all are objects, right. |
There was a problem hiding this comment.
@volodya-lombrozo typo: duplicate object.
There was a problem hiding this comment.
@mximp Done, thanks!
| Moreover, `org`, `org.eolang` , `org.eolang.io` are objects too. | ||
|
|
||
| But where are they? Is it `org.eolang.io` object that contains `stdout` | ||
| attribute, or `org.eolang.io.stdout` is the top-level object itself? |
There was a problem hiding this comment.
@volodya-lombrozo I believe the question is not entirely correct. There is only one top-level object - Φ. All others are attributes of some sort. However at runtime level we do distinguish package objects. So the correct question would sound like "what part of FQN represents the package?"
There was a problem hiding this comment.
@mximp I'm afraid to add "package" term to the blog post, because we use "package" as syntax sugar only. I've already asked about it previously. On the other hand, I agree that we don't have "top-level" object either. Maybe we can name it as follows:
target object
free object
non-attribute object
What do you think?
There was a problem hiding this comment.
@volodya-lombrozo But we do have "package objects" in runtime: namely they are the special objects which are represented not by standard .eo file, but by a location (or path) containing it's attributes (other objects, including other packages). So I believe package is not just a syntactic sure, but has a real representation.
All suggested names, imo, are unclear and misleading.
There was a problem hiding this comment.
@mximp Please, check that thread. I was curious about packages some time ago too. It's not my words:
@volodya-lombrozo there are no packages in EO, but only objects -- this is the beauty/ugliness of the language. org is an object, org.eolang is an object, org.eolang.int is also an object, finally, org.eolang.int.plus is also an object. They are four object with equal rights and responsibilities. I believe that it's the job of a compiler: how to find out which object to load from where. The probing mechanism may not be perfect in its current implementation, but we must make it perfect.
@yegor256 We need your help here.
There was a problem hiding this comment.
@volodya-lombrozo I believe there is no contradiction here. Packages are objection in terms of concept: they have attributes that are accessed the same way. But these object has special treatment in runtime (PhPackage class) and special syntax for definition in EO (+package meta). That's why you can't find any code for a package.
There was a problem hiding this comment.
@mximp I believe we have to write down the meaning of the package somewhere (maybe in the blog post). This ambiguity makes it difficult to reason about that term and I'm afraid to use it. When the meaning will be clear we can change current blog post. What do you think?
There was a problem hiding this comment.
@volodya-lombrozo The term "top-level object" is even more confusing than "package". How would you define it?
There was a problem hiding this comment.
@volodya-lombrozo As I mentioned all of those three terms are unclear. They are not part of any commonly used glossary. On the other hand "package" is totally understandable term. In the context of the blog post it doesn't require any explanation.. I still suggest the term "package object" defined as "special object type which has no corresponding EO source and whose attributes are other objects tagged by package name".
_posts/2023/03/2023-03-13-probing.md
Outdated
| During the compilation of the application from the example above, the compiler | ||
| will create a list of all possible objects that the application might require | ||
| and add them to the `meta` section. This list ensures that the compiler is aware | ||
| of all the necessary objects and will try to locate them as needed: |
There was a problem hiding this comment.
@volodya-lombrozo "all the necessary objects" -> "all object candidates"
There was a problem hiding this comment.
@mximp Done, thanks!
_posts/2023/03/2023-03-13-probing.md
Outdated
| </metas> | ||
| ``` | ||
|
|
||
| In the EO language, the compiler does not differentiate between top-level |
There was a problem hiding this comment.
@volodya-lombrozo "the" should no be here.
There was a problem hiding this comment.
@mximp Done, thanks!
| ... | ||
| ``` | ||
|
|
||
| The index file contains a list of top-level objects that can be used in the |
There was a problem hiding this comment.
@volodya-lombrozo again, it's not fully correct to use naming "top-level objects". We have no such notion.
|
@yegor256 Could you have a look, please? |
|
@yegor256 Reminder |
|
@volodya-lombrozo since it's no more relevant, may be you should close that PR? |
|
As mentioned @maxonfjvipon, this PR isn't relevant anymore, so I close it |
Add blog post about probing.
Closes: #28