Traducción al español o cualquier idioma

Open maljos opened this issue 5 months ago • 0 comments

Análisis de Ownership

4.1 ¿Qué es el Ownership? Cito:

_"El ownership es un conjunto de reglas que definen cómo un programa de Rust administra la memoria. Todos los programas tienen que administrar la forma en que usan la memoria de un computador mientras se ejecutan. Algunos lenguajes tienen recolección de basura que busca regularmente la memoria que ya no se usa mientras el programa se ejecuta; en otros lenguajes, el programador debe asignar y liberar la memoria explícitamente. Rust usa un tercer enfoque: la memoria se administra a través de un sistema de ownership con un conjunto de reglas que el compilador verifica. Si alguna de las reglas se viola, el programa no se compilará. Ninguna de las características del ownership ralentizará su programa mientras se ejecuta.

Porque el ownership es un concepto nuevo para muchos programadores, toma un tiempo acostumbrarse. La buena noticia es que a medida que se vuelva más experimentado con Rust y las reglas del sistema de ownership, más fácil le resultará desarrollar naturalmente código que sea seguro y eficiente. ¡Sigue intentándolo!"_

Analisis:

En estos dos párrafos puede verse una contradicción entre si, o es un concepto o es un conjunto de reglas. El concepto es la esencia, mientras que las reglas son las derivaciones de esa escencia. Por lo tanto, las reglas son una consecuencia de la esencia, no su causa.

A manera de ejemplo tomemos el concepto de "propiedad" aplicado a una casa. Las escrituras o contrato definen la propiedad, solo eso, si es individual o grupal, si es sobre una persona natural o jurídica, es irrelevante, lo importante es que el contrato apunta como propiedad o pertenecia (escencia/concepto). Como consecuencia si esa casa se puede vender, arrendar, prestar, declarar como patrimonio, estaran expresadas en las reglas que regirá dicho contrato y bajo que condiciones (claúsulas del contrato). Llevado al ambito de Rust, la variable es irrelevante (se puede llamar como quiera), lo verdaderamente importante es el contrato que establece Rust entre la variable con el contenido que tenga o al que apunte. Por último, esas reglas definen el comportamiento que se debe tener para manejar legalmente las variables, en pocas palabras, promueven una disciplina. En el caso de la casa, si operas fuera de las reglas establecidas de ese contrato serás sancionado con multa o con carcel.

Es obvio que asi como hay lenguajes que son flexibles (C, C++ cada quien pendiente de su basura), están otros que tienen sus contrataciones, en el caso de java tiene un recolector de basura (está pendiente de la basura que arrojan los demás para procesarla, y esto tiene un costo mayor). En el caso de Rust, tiene un vijilante con un bate en la mano para evitar que se arroje basura (aunque si hay un costo, éste es mínimo, casi imperceptible porque no debería haber basura que procesar).

En resumen, quizás si se abordara Ownership desde un enfoque, por ejemplo el que acabo de exponer, inmobiliario su entendimiento sería más intuitivo por dos preguntas sencillas que se derivan en consecuencia:

¿Qué define que alguien o algo sea dueño de una casa? Obviamente no son reglas en el aire, es la tenencia de la titularidad de la propiedad (el contrato).
¿Cómo podría tener alguien que no es dueño de esa casa acceso a ella? Allí aparecen las clausulas, reglas, normativas, etc. Pero en general pueden agruparse de dos maneras:

que el dueño la preste o la arriende (tiempo o ambito limitado), en cuyo caso el dueño reclamará su casa y los ocupantes no podrían quedarse con la titularidad de la casa porque sería una violación.
que el dueño venda, traspase o done la casa, en cuyo caso cambiaría la titularidad del contrato y el antiguo dueño perdería todos los derechos sobre esa propiedad. Cualquier intento del dueño de ejercer algún derecho sobre su antigua propiedad sería también una violación.

Ambas preguntas revelan dos aspectos importantes sobre las variables en Rust: Lo mutable sería la titularidad del contrato (el dueño), lo inmutable serían las condiciones de ese contrato (las reglas).

Esta nueva revelación trae como consecuencia una pregunta autómatica:

¿Cuáles son esas reglas?

Contrato único, la casa no puede tener dos contratos de propiedad. let a = b = String::from("hola"); //Error del compilador
El contrarto tiene una clausula de remodelación: si es permitida o no, y bajo que condiciones.
```
- let mut a = String::from("hola"); //Con remodelaciones permitidas con condiciones```
```
En caso de venta, traspaso o donación, el contrato cambia la titularidad pero no las condiciones del contrato y su dueño anterior pierde todos sus derechos (Move).
```
let b = a;       // Nuevo titular del contrato: b
println!({}, a); // Error de compilación, a perdió todos los derechos del contrato```
```

Si la casa es arrendada o prestada deberá hacerse explicito si los inquilinos pueden o no hacer remodelaciones (borrowing).

Caso 1: Sin remodelaciones

    // El contrato no es mutable, es decir, ni el dueño ni nadie puede realizar remodelaciones
    let mi_casa = String::from("Casa en perfecto estado.");

    mi_casa.push_str(" Voy a prestar la casa."); // El dueño quiere modificar. Genera error de compilación

    // El "inquilino" tiene las llaves, pero no puede hacer remodelaciones.
    puede_remodelar(&mi_casa);

    println!("La casa sigue en su estado original: {}", mi_casa);
}

// Esta función recibe una referencia inmutable. No puede modificarla.
fn puede_remodelar(casa: &String) {
    // Esto causaría un error de compilación. No se puede modificar.
    casa.push_str("...ahora con una nueva pared");
}```


**Caso 2: Con remodelaciones**

```fn main() {
    // El contrato es mutable, es decir, el dueño puede realizar remodelaciones
    let mut mi_casa = String::from("Casa en perfecto estado.");

    mi_casa.push_str(" Voy a prestar la casa."); // Permitido para el dueño

    // El "inquilino" tiene las llaves, pero no puede hacer remodelaciones.
    puede_remodelar(&mi_casa);

    // Si la función `no_puede_remodelar` intentara cambiar `mi_casa`,
    // el compilador lo impedirá.
    println!("La casa sigue en su estado original: {}", mi_casa);
}

// Esta función recibe una referencia inmutable. No puede modificarla.
fn puede_remodelar(casa: &String) {
    // Esto causaría un error de compilación. No se puede modificar.
    casa.push_str("...ahora con una nueva pared");
}```


**Caso 3: Con remodelaciones**

```fn main() {
    // La variable `mi_casa` no es mutable, es decir,
    // ni el dueño ni nadie puede realizar remodelaciones
    let mut mi_casa = String::from("Casa en perfecto estado.");

    mi_casa.push_str(" Voy a prestar la casa."); // Permitido para el dueño

    // El "inquilino" tiene las llaves, y puede hacer remodelaciones.
    puede_remodelar(&mut mi_casa);

    println!("La casa fue modificada: {}", mi_casa);
}

// Esta función recibe una referencia mutable. Se puede modificar.
fn puede_remodelar(casa: &mut String) {
    casa.push_str("...ahora con una nueva pared");
}```

El contrato no podrá modificarse nunca, solo se puede anular y establecer un nuevo contrato.
```
let mut a = String::from("hola");  // shadowing```
```

Aug 17 '25 19:08 maljos