Provide a package for type conversion

[nibra]

As discussed in this comment, it might be useful to add a package that deals with type conversions.

This discussion is used to evaluate the possible scope and other details of such a package.

[korenevskiy]

I took the courage and copied the function description from discussion. To close the previous discussion.
I hope @nibra will join the discussion as an experienced participant.

function isTrue($value){
	if($value === false || $value === null || $value == 0 || $value == '' || $value == 'false' || $value == '0'
		 || $value == 'disabled' || $value == 'off' || $value == 'no' || $value == 'none')
		return false;
	return true;
}

This is an approximate writing of the function. But the need for such a feature in Joomla is obvious.
This function is needed to analyze the attribute values for XML.
each attribute must be repeatedly rechecked for all possible values. Despite the fact that the variants of values for all attributes are the same. The code becomes dirty, and repeated checks create a multiple little cognitive strain.
You constantly need to think about converting types to values when comparing, Which is very distracting from programming.
And there is also no single rule for analyzing XML attributes. Even a young developer will now adapt to the analysis of this function.
The idea was to have a place where you can place this function. But

@nibra I don't understand the purpose of casting types to other types.
It's a good idea, but it sounds like a fairy tale. Or you @nibra have already used a specific package for casting types, and therefore you already have experience how it works.
Or we let's describe specific criteria convert types.
-.Will be type conversion occur for XML and for the Database? The fact is that there are no problems with type conversion for XML, except for determining the true value for an attribute in a comparison condition.
-.The broader meaning of type conversion is in converting database value types to object properties and vice versa.

In the past, I have already written a type conversion function for the properties of objects and database fields.
https://github.com/joomla/joomla-cms/pull/35247/files
The TypeConvert function is in the class Table. (function TypeConvert($value = null, $type = '', $tz = null))
From creating a typed class, it became clear to me. That it doesn't make sense to create a separate type conversion function without using a typed Table class at all. A type conversion for a database can only be created at the same time as a typed table.

This table class is under development. This class is fully operational, and supports full backward compatibility. But testing this class requires a large number of applicants. So I decided to change this Table class. In the future, I will create a TableType class that will inherit from the classic Table class. And it is necessary to make minimal changes to the classic Table class so that it can be the parent of the TableType class.

@nibra Did you mean to create a type conversion package, at the same time to support type conversion for the database ?

[korenevskiy]

    public static function attributeToHungarianNotation($attributeName) {
        $pos1 = strpos($attributeName, '_');
        $pos2 = strpos($attributeName, '-');
        if(empty($pos1) && empty($pos2))
            return $attributeName;
        
        if($pos1){ 
            $as = explode('_', $attributeName);
            $as = array_map(function($a){return ucfirst(strtolower($a));},$as);
            $attributeName = join('', $as);
        }
        if($pos2){ 
            $as = explode('-', $attributeName);
            $as = array_map(function($a){return ucfirst(strtolower($a));},$as);
            $attributeName = join('', $as);
        }
        return lcfirst($attributeName);
    }

echo attributeToHungarianNotation('translate-default'); // result: translateDefault;

I also had a problem with XML attribute names and object property names. The peculiarity is that attribute names are allowed to use underscores and dashes in names. But it is preferable to use only Hungarian Notation in the names of object properties. And multiple checks for the presence of all kinds of attributes for one property, as well as the problem described at the very beginning causes problems. For these purposes, I use one conversion function. Perhaps it will be useful in this case.

[nibra]

@nibra Did you mean to create a type conversion package, at the same time to support type conversion for the database ?

For the time being, this discussion should be open-ended. To solve the Boolean problem, a class is needed that converts string representations into PHP types. However, it may make sense to offer additional conversion classes for other targets, e.g. SQL, perhaps in a later step.

[korenevskiy]

I fully support you that SQL type conversion is not applicable in this topic, since it does not make sense without a typed table. We'll put it off for later.
Let's figure it out here. Do you propose to do a type conversion for each individual field property? For example: if it is a translateDefault attribute, then we will automatically get the Bool type, but if it is a Label attribute, then we should automatically get the string type.
But there is another option, you can convert types based on the values themselves. If the attribute value is 1, then its type will then be an integer, but if the value is TRUE, then the type conversion will be BOOL.
In this case, we cannot know what value will be in the attribute of the XML element for earlier. So at the output we will get several different but similar values. But even in this case we have an analog of type conversion (bool), (int), (string)
For example, type conversion is based on the values themselves. But then it is not clear to what type we will convert the string with the value "1". Such a value can be as a number, but such a value can still remain a string. For example, if the XML attribute Label="1". We will see the same thing with Label="123" and Title="123".

I propose to divide the current task into 2 independent processes. Note that it is the independent processes.
1.Choosing the location of the file with functions, classes.
2. Thinking through the logic and defining the functions in this file.

Later, we may move something and rename it. But now we can make a preliminary (draft) PR, 2-3 functions. This will already be the beginning for discussing the logic of the file. But also at the same time, beginners who do not understand what is at stake can familiarize themselves with the existing library and make their suggestions.

The method written above isTrue() , performs the function only when cast to the BOOL type. Because it is this type that causes problems when cast to a type. Later we can add the toInt(), toString() and other functions. Now let's define a place and a class name for these functions.
\libraries\vendor\joomla\utilities\src\TypeHelper.php
Is it possible here, do you think?

Can we use isTrue() functions without a class, but using with a namespace?
Example:
namespace \Joomla\Type;
or
namespace Joomla\Utilities;

[korenevskiy]

1. It is necessary to consider new types (Boolean, String, Float) from the point of view of typing for programming in the IDE. (Which IDE do you program in? (I use NetBeans))
2. In the examples above, we considered Boolean and String as classes that support string formatting. We want types with formatting. We dream of formatting-enabled types. Maybe we are mistaken? Maybe we need to do the analysis correctly, and just solve the problem with formatting of different types correctly. Metaphor: Similar to the fact that people often want to eat sweets, forgetting that they just need to eat regular food normally. We can also make a mistake about what we need to have. In the C# programming language, we can create a new class by inheriting it from BOOL or from STRING. But there is no such thing in PHP, we do not know when such an opportunity will appear. We will not be able to compare the Boolean type simply with the BOOL type. The magic methods __conain(), __compare() and will not be for several years in PHP. If we create the types "Float", "Integer" they will not be used by anyone, since calling comparison functions from these types will strain and not give advantages in readability and understanding. We are already moving away from the JObject type. I propose to concentrate on the possibilities of formatting strings, perhaps by expanding the formatting of strings, the need for typing types will disappear.

/**
* @param string|array $format A string from the INI or an array to replace the value by the key.
* @param mixed $value  The source of the value
* @param string $type Type to cast the types of the $value attribute; The conversion method.
*  		$type possible values: emoji, roman, bool, int, string(default), float . . .
**/
class JText($format = '', $value = null, $type = ''){
}

// Initialization methods.
$text = new JText()
// or
$text = JText::getInstanse()

// Setting the value
$text->value  = 123;
// Setting the type
$text->type  = 'bool';
$text->type  = 'int';
$text->type  = 'float';
$text->type  = 'emoji';
$text->type  = 'roman';

// But if the property value was not set, then the property value will be used defined for this $type
$text->format= '';
$text->format= [true="show", false="hide"];

// The value is in its original state.
$text->source = $element['label'];

// The value will be converted when assigned to the desired type. By default to a string.
$text->value = $element['label'];
// But the source property will still have the value of the original state.
$text->source = $element['label'];

// The property is read-only.
echo $text->length;

// Supported methods: $haystack, $needle
$text->conaint($needle);
$text->start_with($needle);
$text->ends_with($needle);
$text->pad($length, $pad_string = " ");
$text->replace($search, $replace);
$text->split($string);
$text->ireplace($search, $replace);
$text->toupper();
$text->tolower();
$text->pos($needle);
$text->substring($start, $end);
// and
$text->_();
$text->sprintf($args);


// Print.
echo $text->value;
//Equivalent to
echo $text;
//Equivalent to
echo $text->_();
//Equivalent to
echo $text->sprintf($args);


// A short form of formatting.
echo JText::getInstanse('', 'thumbsup','emoji');	// Result: 👍
echo JText::getInstanse('', 'enable','bool');		// Result: 'true'
echo JText::getInstanse('', 116, 'roman');		// Result: MMXXII
echo JText::getInstanse('', 'smile', 'emoji');		// Result: 😀

// Enumeration of supported types.
JText::type_bool;
JText::type_roman;
JText::type_emoji;

//Support for objects and arrays
$user = ['name' => 'Agata', 'mail' => 'agata@mail.ru', 'phone' => '+79004881200', ];

// example 1
echo JText::getInstanse('My name %s, my mail %s, my phone %s', $user); 
// or
echo JText::getInstanse('FIELD_OPTIONS_TITLE', $user); 

// example 2
$text->format = 'My name %s, my mail %s, my phone %s';
$text->value = $user; 
echo $text;

// Result: 'My name Agata, my mail agata@mail.ru, my phone +79004881200'

// verify type
$text->type = 'int'; 
$text->value = '123'; 
echo gettype($text->value); 	// Retrun: INTEGER
echo gettype($text); 		// Retrun: STRING

I'm not good at the intricacies of formatting with parameters. But these are all the details of the work.

$text->format = "My number: %s";
$text->type = 'integer';
$text->value = "123";
// But 
$text->value == 123; // Return: FALSE; // This is wrong! It should work differently.
// We will make sure that these values are equal!
$text->value == 123; // Return: TRUE;
// Therefore, the string format will be executed only when **`__toString()`** is called;
echo $text; // Return: "My number: 123"	// it is as STRING type
echo $text->value; // Return: 123 	// it is as INT type

[nibra]

How will that make dealing with the original problem easier?
(assume $field['show_title'] contains 'show')

$showTitle = new JText();
$showTitle->type  = 'bool';
$showTitle->format = [true="show", false="hide"];
$showTitle->value = $field['show_title'];
echo $showTitle; // Result: 'show'
$showTitle->negate();
echo $showTitle; // Result: 'hide'

vs.

$showTitle = $field['show_title'] === 'show';
echo $showTitle ? 'show' : 'hide'; // Result: 'show'
$showTitle = !$showTitle;
echo $showTitle ? 'show' : 'hide'; // Result: 'hide

vs.

$showTitle = new Boolean($field['show_title']);
echo $showTitle; // Result: 'show'
$showTitle->negate();
echo $showTitle; // Result: 'hide'

[korenevskiy]

$showTitle = new Boolean($field['show_title']);
echo $showTitle; // Result: 'show'
$showTitle->negate();
echo $showTitle; // Result: 'hide'

You are right only when a boolean value can be represented as show & hide.
But besides show&hide, there are other interpretations, It can be On & Off or Enable & Disable or Yes & No or Ok & None. How does this class when printing choose the correct display method?

If the attribute has the name $field['display'], then it is Show&Hide, but if the attribute has the name Enable, then it is On&Off. The Boolean type does not have a specific interpretation, the Boolean class cannot be applied without specifying the format for it, how it should be displayed when printing. In your Boolean class, you need to specify the parameter $showTitle->format = [true="show", false="hide"]; just as it is specified in my example.

$showTitle = new Boolean([true="show", false="hide"], $field['show_title']);
echo $showTitle; // Result: 'show'
$showTitle->negate();
echo $showTitle; // Result: 'hide'

or

$showTitle = new Boolean( $field['show_title']);
$showtitle->format = [true="show", false="hide"];
echo $showTitle; // Result: 'show'
$showTitle->negate();
echo $showTitle; // Result: 'hide'

As a result, we will get the same thing, but just with a different name in the class name.

[korenevskiy]

// this format can be defined as a constant in the JText class;
JText::boolYesNo 	// as [true="yes", false="no"]
JText::boolShowHide 	// as [true="show", false="hide"]
JText::boolOnOff 	// as [true="on", false="off"]

$showTitle = new JText(JText::boolShowHide, $field['show_title'],'bool');
echo $showTitle; // Result: 'show'
$showTitle->negate();
echo $showTitle; // Result: 'hide'

In this case, the type name is specified as a parameter in the constructor. But the rest of the functionality will be the same.

No matter how the class is called, we cannot avoid the format property. For any class name Boolean, Float, String, Integer, the format property will be a mandatory part. I want to explain to you that no matter how the class is called, the formatting of the object of this class will be the basis. I separated this formatting capability from the class object itself (Boolean,String,Float,Integer), and described it in the JText class; After that, it became clear to me that we needed not these Boolean, String, Float, Integer classes, but the ability to format them in a universal form with extensive capabilities and support for a short form of writing.

[nibra]

Your example

$showTitle = new JText(JText::boolShowHide, $field['show_title'],'bool');
echo $showTitle; // Result: 'show'
$showTitle->negate();
echo $showTitle; // Result: 'hide'

will not work, as JText does not have a negate() method. A method with that name only makes sense for booleans, not for text.

[nibra]

How does this class when printing choose the correct display method?

It internally knows the valid true/false pairs and decides which one to choose depending on the value provided to the constructor.

$var = new Boolean('show');
echo $var; // Result: 'show'
$var->negate();
echo $var; // Result: 'hide'

$var = new Boolean('on');
echo $var; // Result: 'on'
$var->negate();
echo $var; // Result: 'off'

$var = new Boolean('yes');
echo $var; // Result: 'yes'
$var->negate();
echo $var; // Result: 'no'

and so on.

[nibra]

After that, it became clear to me that we needed not these Boolean, String, Float, Integer classes, but the ability to format them in a universal form with extensive capabilities and support for a short form of writing.

In that case, I see no benefit over the native PHP way to solve that:

$showTitle = $field['show_title'] === 'show';
echo $showTitle ? 'show' : 'hide'; // Result: 'show'
$showTitle = !$showTitle;
echo $showTitle ? 'show' : 'hide'; // Result: 'hide

Although the Boolean class does not require significantly less code, the benefit is that you don't need to know that $field['show_title'] encodes true and false as 'show' and 'hide'. Anything being more complex than the native PHP way does not make sense, because nobody will ever use it.

[korenevskiy]

$var = $field['show_title'];
echo $var; // Result: 'yes'
boolean_negate($var);
echo $var; // Result: 'no'

or

$var = 'show';
echo $var; // Result: 'yes'
boolean_negate($var);
echo $var; // Result: 'no'

/ * *
* @param mixed  $var 
* @return string
*/
function boolean_negate($var) : string{
}

an easy-to-understand script, easy to read.
or

// Static methods
echo boolean::negate($var);

[korenevskiy]

@nibra
Do you think this equality should work like this?

echo ((new Boolean('yes')) != (new Boolean('on')));

[korenevskiy]

Of course we need to do this. We can use an array. Find the logical value by using the string key.

[korenevskiy]

@nibra
It is also necessary to achieve so that the object can be compared with the usual Bool value.

$var = new Boolean('yes'); 
echo $var == true ? "True" : "False";	// Return: "True"
$var = new Boolean('no'); 
echo $var == false ? "False" : "True";	// Return: "False"

This is possible?

[nibra]

Not with PHP, until it will provide operator overloads, which not seems to happen.

[korenevskiy]

Not with PHP, until it will provide operator overloads, which not seems to happen.

I know that rebooting in PHP does not exist. I wanted to offer an idea.
Can the __toString() method return the desired value so that it can meet the condition above?

[korenevskiy]

@nibra
I checked, such a comparison is not possible in PHP .
Let's ask other participants how to recommend creating comparisons of stringed instin values and how to implement this.