Alternative names to defmodulep (split thread)

The problem with that names are p and private parts, because it’s not working as same as defp (again p - private - here). The point here is to have different naming like internal and optionally short it to i instead of private/p. So defmodulep as well as defprivate causes too many confusion. To be honest defprivate is even worse, because it does not refers to module in name.

defmodule Example do
  defprivate Sample do
    # …
  end

  defp sample do
    # …
  end
end

Do you mean that internal used this way will avoid the confusion?

defmodule Example do
  internal Sample do
    # …
  end

  defp sample do
    # …
  end
end

Why not go for private then, it’s used practically in any language, even Ruby refers to private to declare a private something (a Module in this case) and uses the keyword private to declare private methods

module A
  module B
    def self.a; puts("A"); end
  end

  private_constant :B
  def self.a
    B.a
  end  
end

2.3.1 :074 > A::B.a
NameError: private constant A::B referenced

2.3.1 :075 > A.a
A
 => nil

My initial idea was defprivatemodule, but it’s too long and def_private_module it’s not in style.

Maybe it’s a bias I have, but I prefer the emphasis on the private part rather than on the module one.

I said about internal/i and keep module part which you didn’t.

So here is real example:

defmodule Example do
  defmodulei Sample do
    # …
  end
  
  defp sample do
    # …
  end
end

Because private function (defp) is working differently than private module in this proposal (defmodulep). Look that private functions can’t be accessed in other modules at all, but there would be a way to access private modules even in other app (look my question about possible hack).

I’m sorry, I’m confused.
Do you mean defmodulei?

Of course private functions work differently than private modules, they serve a different purpose.
The proposal was about private modules, but they are more like friend in C++.

I could have private modules with private functions…
In fact I probably will.

Yup as you talking about private/p → defprivate/defmodulep I’m talking about internal/i (just for example) → defmoduleinternal/defmodulei.

Now look that both defprivate / defmodulep refers to private word as same as defp, but as you see they work differently, so there can’t be private/p word in proposed name. You know other languages, me too, but it does not mean that every newbie would know other languages as well. private which means two different things could be confusing for beginners.

Not really a big difference…
private or internal are equivalent to my eyes.

I just see that defmodulei or defmoduleinternal are longer then defmodule and know it’s not a regular module.
In this regard, a p at the end helps more than an i.

They are both private.
At a different granularity, but still private (AKA not accessible outside of their scope).
A private function is not accessible outside of the module that declares it, a private module is not accessible outside of <still debating>.

It really means the same thing.

It’s not a point to have big difference. The point is to have different naming even if those words are synonyms.

Again and again, helps for you, me and more experienced Elixir developers. Beginner would be confused why private/p does not work as same in both cases. Look that not everyone needs to read this proposition and not everybody even need to understand it.

No, they are not private as same as functions are. There are ways to access it outside unlike private functions. Depends on implementation there are few ways to access it.

Look:

defmodule Example do
   def private, do: 5
end
defmodule Example2 do
   def private, do: "Sample"
end

private means private, but 2 different implementations are 2 different implementations - not the same thing.

Imagine that I would write my own phoenix library. It would be also server, but it would work differently. Naming it phoenix is a big mistake as other developers seeing it could think that it’s fork or something like that. Looking at source they would find that there are 100% different even if both libraries do similar thing. Having same naming for different things is a big mistake as it’s confusing for others. While one team could assume that when we are saying phoenix we mean something else other people would see it still as original phoenix.

Private means

belonging to or for the use of one particular person or group of people only.

That’s exactly what private functions and modules are.
But that’s not really relevant to the discussion, it’s just a minor implementation detail.

I guess we can agree to disagree on this.

Again:

defmodule Example do
  @doc "This belongs only to use of one particular person or group of people."
  def private, do: 5
end

defmodule Example2 do
  @doc "This belongs only to use of one particular person or group of people."
   def private, do: "Sample"
end

defmodule PrivateTest do
  use ExUnit.Case do

  test "example" do
    assert is_integer(Example.private())
    # 2nd assertion would fail
    assert is_integer(Example2.private())
  end
end

# now look:
defmodule Problem do
  def confuse(module), do: apply(module, :private, [])
end
Problem.confuse(Example) # Integer
Problem.confuse(Example2) # String

Person A sign agreement for some job offer. Person B does not know if person A receives payment for hours, specific issue or maybe for whole specific project. That’s why person A should say is saying about agreement name instead of saying saying just about agreement. In any case he/she is working, but this does not mean all cases are exactly same. We could guess, we could assume, but nothing good would happen if we would do so.

That’s why people are using names. If you name something properly other people would understand you without taking care of “source”. Well we could name every pet just pet, because basically all pets are pets. Now you can’t filter images only for cats, because there are no cats - there are only pets. We could generalize everything and saying “thing” on everything, but that would be just confusing.

Just take a look at:

Now say again that private in both cases means exactly same.

This topic does not talk about making some modules private. We are talking about guarding some modules to … (show warning, don’t allow access it unless). This is definitely not how private functions are working.

You think that private is private and there is no way to access private modules. In my linked example I show how it’s possible in specific implementation case. That’s why I mean it’s confusing. They are named similarly, but works differently. private means private, but here we have 2 different contexts which makes private word more than one meaning and that could be confusing.

I really don’t want to monopolize the discussion.

Most of all, I’m not supporting any solution in particular, once we established private modules are going to be a thing, I’ll gladly accept any syntax for it, Jose and the Elixir team have already proven capable of handling those kind of changes with care.

defmdulei, defmodulep, definternalmodule they’re all fine to me.

But one thing is for certain: private modules are private modules.
They are something hidden from something else, based on some rule.

That’s not gonna change because rules are different for different elements.

Attributes are private too: they are only visible from inside the module and at compile time.
They just don’t have private in the name.

Private functions are private as well (hence the name).
Think of them as something like

defp private_func, visible_to: [MyApp.A] do
  ...
end

where visible_to can be omitted and defaults to [__MODULE__].

Private modules are private in the same way, but from an higher level, since we are dealing with cross module visibility and given that modules have only been public until now.
The fact that privateness is not enforced doesn’t make them any less private.

A simple analogy is private offices: nobody is locking himself up inside them, anybody could open the door and see what you’re doing, but they’re private nonetheless, and people usually knock, even though they are not forced to.

No, I don’t.

For now…
I think it’s just a matter of smoothing the transition to a full private module implementation.
Besides, if we are going down that road and implementing them, I would prefer the real deal.
I would also have preferred private to be an attribute of the module, even though I’m not a big fan of decorators, this one made sense to me and I think it’s more flexible.

I also think using internal would cause major headaches when they are going to become private for real (I bet it’s not gonna be that far in the future).
What’s going to happen to internal?
will it be deprecated? or will it be repurposed?

In the end private is just more future proof.
And the semantic is preserved.

The risk of confusion is exaggerated in my opinion: novices will read private and think of something they should not rely on, just like private functions, and that’ll be a good guess, even if they could work around the limitation, while experienced programmers are suppose to know what they are doing.