Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
This is a follow up of my earlier post here:
Ada: Understanding private types and understanding packaging
An implementation for the Rectangular type was made using one implementation i.e. Rectangular_Method_1 and a specification file and a body file were required for this implementation.
If we want to have another implementation Rectangular_Method_2 available to the user then the main file rectangular_Form.ads can be changed to
-- with Rectangular_Method_1;
-- package Rectangular_Form renames Rectangular_Method_1;
with Rectangular_Method_2;
package Rectangular_Form renames Rectangular_Method_2;
Questions
Is this the right way in software engineering to allow for another implementation in that the test file test_rectangular_form.adb remains the same for a different implementation?
If we create a second implementation Rectangular_Method_2, Is there a need to create a separate specification file in addition to the compulsory new body for this new implementation? There is the need however to provide the same procedures/functions for Vector_Basis_r, Set_Horz, Get_Horz etc in the new implementation so that we can call them in test_rectangular_form.adb.
Thanks...
If you use GNAT, you can use GPR files for the project. In there you can change the filename for specific packages, for example:
for Specification (Rectangular_Form) use "Rectangular_Method_1.ads";
for Implementation (Rectangular_Form) use "Rectangular_Method_1.adb";
you can even set this depending on an environment variable.
If your spec files all should look the same, you can use a Rectangular_Form.ads and only use the Implementation line from above.
An example GPR file could look like this:
project Example is
type Methods is ("normal", "something_else");
Method : Methods := external ("METHOD", "normal");
package Naming is
case Method is
when "normal" =>
for Implementation ("Example") use "example_normal.adb";
when "something_else" =>
for Implementation ("Example") use "example_something.adb";
end case;
end Naming;
end Example;
Then, you can use gnatmake -P example.gpr to compile it depending on your METHOD variable, or using a -XMETHOD=... parameter for gnatmake or just use the provided default value.
The example_*.adb should all contain the body of the package Example, not Example_Normal, etc..
Another way to do this would be to use tagged types.
package Rectangular is
type Instance is abstract tagged private;
procedure Vector_Basis_r (A : in Long_Float; D : out Instance);
procedure Set_Horz (R : in out Instance; H : Long_Float);
function Get_Horz (R : Instance) return Long_Float;
private
type instance is tagged null record;
end Rectangular;
with Rectangular;
package Rectangular_Method_1 is
type Instance is new Rectangular.Instance with private;
...
private
type Instance is new Rectangular.Instance with
record
Horz, Vert: Long_Float;
end record;
end Rectangular_Method_1;
(similar implementation for Rectangular_Method_2).
Then I believe you can write your code that uses it this way:
with Rectangular_Method_1;
with Rectangular_Method_2;
...
-- My_Rectangle : Rectangular_Method_1.Instance;
My_Rectangle : Rectangular_Method_2.Instance;
My_Rectangle.Set_Horiz(Whatever_Value);
...
In other words, all you'd have to change when switching between the two is the type names. Your client could even get rid of those changes by using a single subtype at the top.
subtype Rectangle_Instance is Rectangular_Method_2.Instance;
This would also give you the ability to move common code/fields up into the base class (package), which I think is sort of what you were after.
Related
I'm kinda new to tensorflow/keras, and I'm deploying my neural network on arduino, and I I've looked everywhere on the internet, and could not find what the following integer does (specifies):
static tflite::MicroMutableOpResolver**<3>** micro_mutable_op_resolver;
micro_mutable_op_resolver.AddFullyConnected();//
micro_mutable_op_resolver.AddLogistic();//
micro_mutable_op_resolver.AddRelu();
If I put 0,1,2 into this statement, my code does not work properly, only works, when numbers are 3 or larger..
Thank you for your help in advance!
Jonathan
It is a template parameter specifying the maximum number of ops you can register with the tflite::MicroMutableOpResolver object.
You followed that line with three *.Add function calls (i.e. registering three operations), therefore you need the resolver to have a capacity of at least 3.
TensorFlow is open source, so you can always look to the code for answers. Check the header file here. Take note of the class definition:
template <unsigned int tOpCount>
class MicroMutableOpResolver : public MicroOpResolver {
...
tOpCount is the value you set to 3 in your code. You can trace it though the header if you want to see details of how it is used.
If template parameters are new to you (from the question it seems you are fairly new to C++ as well), you can get all the details you need on cppreference (your case is a "Non-type template parameter"). Any decent C++ tutorial should also cover the topic in a more newbie-friendly manner.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 6 years ago.
Improve this question
I need a way to make really encapsulated variables in Perl, without using any frameworks like Moose, so that you can access the instance variables only through getters and setters. There should be private instance variables.
The subroutines respectively methods are not a problem, because you can define them so that they can be used just through an instance respectively a reference. But variables you can always access via the package name, like class-vars.
Is there any way to prevent that?
It sounds like you're trying to prevent people from accessing the instance variables other than through the accessors; is that right?
Perl is a language for polite people, and the way you stop programmers from doing things you don't want them to do is to ask them not to. Yes, there are hacks, and the most obvious one here would be to make each object a closure (here's an article about it from the Perl Journal) but there are almost always ways around them, so you won't be able to stop the determined impertinent hacker
One of Larry Wall's excellent attributions is this, which explains my point superbly
Perl doesn't have an infatuation with enforced privacy. It would prefer that you stayed out of its living room because you weren't invited, not because it has a shotgun
People tried to achieve this kind of thing with inside out objects. This presentation by David Golden explains it perfectly:
Inside-out objects first presented by Dutch Perl hacker Abigail in 2002
Spring 2002 – First mention at Amsterdam.pm,
June 28, 2002 – YAPC NA "Two alternative ways of doing OO"
July 1, 2002 – First mention on Perlmonks
Gained recent attention (notoriety?) as a recommended best practice with the publication of Damian Conway's Perl Best Practices
Despite their benefits, they bring significant complexity and are not universally welcomed
There are a number of modules that try to facilitate this type of programming.
I find them rather cumbersome, and they have since fallen out of favor.
You can also find them mentioned in perldoc perlobj:
In the past, the Perl community experimented with a technique called "inside-out objects". An inside-out object stores its data outside of the object's reference, indexed on a unique property of the object, such as its memory address, rather than in the object itself. This has the advantage of enforcing the encapsulation of object attributes, since their data is not stored in the object itself.
This technique was popular for a while (and was recommended in Damian Conway's Perl Best Practices), but never achieved universal adoption. The Object::InsideOut module on CPAN provides a comprehensive implementation of this technique, and you may see it or other inside-out modules in the wild.
To do really private variables you should use closures:
{
my $x;
sub get {
return $x;
}
sub set {
$x = shift;
}
}
set( 3 );
print get(); # prints 3
print $x; # ERROR
# Example with objects
package Class;
sub new {
bless {}, 'Class';
}
{
my $storage = {};
sub get {
$self = shift;
return $storage->{ "$self" };
}
sub set {
$self = shift;
$storage->{ "$self" } = shift;
}
}
package main;
print Class::x; #ERROR
$z = Class::new();
$z->set( 3 );
$y = Class::new();
$y->set( 5 );
print $y->get(); # 5
print $z->get(); # 3
The $x is local to the block. None except set and get may access it.
"$self" will be like "Class=HASH(0x1cf9160)". Because of each object has its own address in memory "$self" will never collision.
But actually you are not required to do so in other case that will be a stick in your wheel
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
When is it appropriate to write a method with a variable number of arguments (like NSString's +stringWithFormat:)?
A brief search of variadic methods from Apple seems to include only two classes: when creating a data structure (NSArray's +arrayWithObjects:, NSSet's +setWithObjects:), or when formatting a string (NSString's +stringWithFormat:, NSPredicate's +predicateWithFormat:).
Apple's documentation for variadic methods includes an example that is subtly different from the previously mentioned data structure methods, but still in the same camp.
Is it appropriate to use variadic methods in any other context? Does Apple?
When is it appropriate to write a method with a variable number of arguments (like NSString's +stringWithFormat:)?
This method uses a printf-like attribute which checks the format string against the additional parameters. You should always add an attribute to your methods/functions when using a format string.
A brief search of variadic methods from Apple seems to include only two classes: when creating a data structure (NSArray's +arrayWithObjects:, NSSet's +setWithObjects:), or when formatting a string (NSString's +stringWithFormat:, NSPredicate's +predicateWithFormat:).
This form uses a nil sentinel. It's actually a bit relaxed because an unexpected nil can silently truncate your parameters without error or warning. As an example, the (new-ish) Objective-C Literals do not use this form; they use implementations which also take count as a parameter, and it is an error to pass nil elements.
Is it appropriate to use variadic methods in any other context?
It's used in many places in C, and there are also variadic macros. Generally, you should look for alternatives because variadics are a less safe API.
One place I will use them is if I need to wrap an API. In that case, I only forward the parameters to the API which takes the va_list.
You can find safer alternatives for almost every use case, especially since the introduction of blocks.
To my knowledge, Cocoa's uses of functions with variable number of arguments is limited to the two categories that you have mentioned. For example, NSLog and NSAssert can be considered functions from the second category, because it formats a string.
However, functions with variable number of arguments can be very useful when in other situations.
For example, you can define an API for evaluating expressions that looks like this:
NSNumber *res = [Evaluator evalExpression:#"%1 + %2 * %3", #10, #20, #5];
// returns #110
Another example could be an API for composing XML, like this:
MyXmlTree *tree = [MyXmlTree addElementWithTag:#"root" andChildren:
[MyXmlTree elementWithTag:#"hello"]
, [MyXmlTree elementWithTag:#"world"]
, nil];
The second example is a more complex case of composing a data structure (i.e. composing a tree, rather than defining a linear structure).
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I cannot understand for whom Dart style-guide was written?
Dart Style Guide
Term PREFER form this guide:
"PREFER guidelines are practices that you should follow. However, there may be circumstances where it makes sense to do otherwise. Just make sure you understand the full implications of ignoring the guideline when you do"
Now one of the main practices that often discussed and, of course, we should follow it:
PREFER using var without a type annotation for local variables.
In short words, use type annotation in function body not recommended (except some very specific situations).
But when I look into source code of the Dart SDK I often see just the opposite.
Just one sample from many other similar.
runtime/lib/collection_patch.dart
Example:
void operator []=(K key, V value) {
int hashCode = key.hashCode;
List buckets = _buckets;
int length = buckets.length;
int index = hashCode & (length - 1);
_HashMapEntry entry = buckets[index];
while(entry != null) {
if (hashCode == entry.hashCode && entry.key == key) {
entry.value = value;
return;
}
entry = entry.next;
}
_addEntry(buckets, index, length, key, value, hashCode);
}
Why Dart team used type annotations for local variables instead of var?
I cannot understand for whom Dart style-guide was written?
It was written for Dart programmers. Why? Because..
As we build up an ecosystem of Dart code, it’s helpful if it follows a consistent coding style. A dedicated style guide for Dart helps us make the most of the features unique to the language and makes it easier for users to collaborate.
And it is up to each programmer or team whether or not to follow these guidelines, which are just a suggestion.
I would like to declare some "user-defined compiler-constants" to keep my specification files as "constant" as possible. This is something common in C++, e.g. :
// misc/config.hh
namespace misc
{
typedef std::shared_ptr<A> A_ptr;
namespace arch = ibmpc;
}
// misc/code.hh
#include "misc/config.hh"
namespace misc
{
void function p(A_ptr a);
}
Which would be in Ada :
-- misc.ads
package Misc is
use Types; ----> forbidden !
procedure P(A : A_Access);
end Misc;
-- misc-types.ads
package Misc.Types is
type A_Access is A'Access;
end Misc.Types;
Of course this does not work since use is a context keyword...hence my question : how is it possible to do something with the same results in Ada ?
I think this is a reasonable mapping from your C++ original to Ada:
To start with, corresponding more-or-less, I think, to your namespace misc, in file misc.ads,
package Misc is
end Misc;
Then, corresponding to config.hh, in file misc-config.ads,
package Misc.Config is
type A is (For_Example, An_Enumeration);
type A_Access is access A;
end Misc.Config;
(which could, of course, also reference types in Misc). Then, corresponding to code.hh, in file misc-code.ads,
with Misc.Config;
package Misc.Code is
use Config;
procedure P (A : A_Access);
end Misc.Code;
Personally I wouldn’t use Config;, at any rate in specs - it can make it difficult to work out where something is defined. Note, you can say use Config; or use Misc.Config; where shown, because you’re in a child of Misc; in the context clause, which is also OK, you would have to use Misc.Config;.
Ok, while I see what you're trying to do you're going about it wrong.
The problem you have with the given sniplets is this: circular dependency.
Now Ada has a great way of managing circular dependency by making it non-circular (in a sense) through it's use of specs and bodies. As the two are discrete, we can have two sets of spec/body files where the body references the other's spec precisely because the specs are publicly visible.
As an example, admittedly ridiculous; let's use fountain-pens and ink-cartridges.
With Cartridge;
Package Pen is
Subtype Model_Number is Positive Range 1000..3304;
Type Fountain_pen is private;
-- Pen procedures
private
Type Fountain_pen is Record
Model : Model_Number;
Ink : Cartridge.Ink_Cartridge;
end record;
end Pen;
and
With Pen;
Package Cartridge is
Type Ink_Cartridge is private;
-- Ink procedures
private
Type Ink_Cartridge is record
Color : Integer; -- I'm being lazy.
This_Pen : Pen.Fountain_pen;
end record;
end Cartridge;
and
Package Body Pen is
--- Pen Stuff
end Pen;
Package Body Cartridge is
-- Ink stuff
end Cartridge;
(Not compiled.)
I forget how to create a component of a circularly-nested type though... Anyway, you should get the general idea there. But what you're wanting is fundamentally different than mutually dependent types; what you want is some sort of container for your constants.
I would recommend using child packages. Something like Misc and Misc.Constants; where you place your base-types into Misc, and the constants into Misc.Constants. If your types are dependent on your constants you might make a separate child package for them Misc.Types and use the mutual withing as shown above.
You could put the child package spec inside the parent package spec, like this:
package Misc is
package Types is
type A is private;
type A_Access is access A;
-- other stuff
end Types;
procedure P (A : Types.A_Access);
end Misc;
you can even use Types; after the declaration of Misc.Types.