adamdebreceni commented on a change in pull request #900:
URL: https://github.com/apache/nifi-minifi-cpp/pull/900#discussion_r486855212
##########
File path: extensions/bustache/ApplyTemplate.h
##########
@@ -61,7 +61,7 @@ class ApplyTemplate : public core::Processor {
class WriteCallback : public OutputStreamCallback {
public:
WriteCallback(const std::string &templateFile, const
std::shared_ptr<core::FlowFile> &flow_file);
- int64_t process(std::shared_ptr<io::BaseStream> stream);
+ int64_t process(const std::shared_ptr<io::BaseStream>& stream);
Review comment:
I would say, that using `const shared_ptr<>&` is certainly an
improvement, as @lordgamez said it does not force us to take ownership, and it
is agreement with the proliferation of managed pointers in the rest of the
system (so it lets us call into interfaces expecting a managed ptr), I don't
have a strong opinion about it though, because I plan on removing the whole
`*StreamCallback` stuff, so if you feel like it should be changed, decide which
one should it be:
1. shared_ptr<BaseStream>
2. const shared_ptr<BaseStream>&
3. BaseStream&
4. BaseStream*
5. gsl::not_null<BaseStream&>
##########
File path: extensions/bustache/ApplyTemplate.h
##########
@@ -61,7 +61,7 @@ class ApplyTemplate : public core::Processor {
class WriteCallback : public OutputStreamCallback {
public:
WriteCallback(const std::string &templateFile, const
std::shared_ptr<core::FlowFile> &flow_file);
- int64_t process(std::shared_ptr<io::BaseStream> stream);
+ int64_t process(const std::shared_ptr<io::BaseStream>& stream);
Review comment:
I would say, that using `const shared_ptr<>&` is certainly an
improvement, as @lordgamez said it does not force us to take ownership, and it
is agreement with the proliferation of managed pointers in the rest of the
system (so it lets us call into interfaces expecting a managed ptr), I don't
have a strong opinion about it though, because I plan on removing the whole
`*StreamCallback` stuff, so if you feel like it should be changed, decide which
one should it be:
1. `shared_ptr<BaseStream>`
2. `const shared_ptr<BaseStream>&`
3. `BaseStream&`
4. `BaseStream*`
5. `gsl::not_null<BaseStream&>`
##########
File path: extensions/bustache/ApplyTemplate.h
##########
@@ -61,7 +61,7 @@ class ApplyTemplate : public core::Processor {
class WriteCallback : public OutputStreamCallback {
public:
WriteCallback(const std::string &templateFile, const
std::shared_ptr<core::FlowFile> &flow_file);
- int64_t process(std::shared_ptr<io::BaseStream> stream);
+ int64_t process(const std::shared_ptr<io::BaseStream>& stream);
Review comment:
I would say, that using `const shared_ptr<>&` is certainly an
improvement, as @lordgamez said it does not force us to take ownership, and it
is agreement with the proliferation of managed pointers in the rest of the
system (so it lets us call into interfaces expecting a managed ptr), I don't
have a strong opinion about it though, because I plan on removing the whole
`*StreamCallback` stuff, so if you feel like it should be changed, decide which
one should it be:
1. `shared_ptr<BaseStream>`
2. `const shared_ptr<BaseStream>&`
3. `BaseStream&`
4. `BaseStream*`
5. `gsl::not_null<BaseStream*>`
##########
File path: extensions/bustache/ApplyTemplate.h
##########
@@ -61,7 +61,7 @@ class ApplyTemplate : public core::Processor {
class WriteCallback : public OutputStreamCallback {
public:
WriteCallback(const std::string &templateFile, const
std::shared_ptr<core::FlowFile> &flow_file);
- int64_t process(std::shared_ptr<io::BaseStream> stream);
+ int64_t process(const std::shared_ptr<io::BaseStream>& stream);
Review comment:
I would say, that using `const shared_ptr<>&` is certainly an
improvement, as @lordgamez said it does not force us to take ownership, and it
is agreement with the proliferation of managed pointers in the rest of the
system (so it lets us call into interfaces expecting a managed ptr), I don't
have a strong opinion about it though, because I plan on removing the whole
`*StreamCallback` stuff, so if you feel like it should be changed, decide which
one it should be:
1. `shared_ptr<BaseStream>`
2. `const shared_ptr<BaseStream>&`
3. `BaseStream&`
4. `BaseStream*`
5. `gsl::not_null<BaseStream*>`
##########
File path: extensions/bustache/ApplyTemplate.h
##########
@@ -61,7 +61,7 @@ class ApplyTemplate : public core::Processor {
class WriteCallback : public OutputStreamCallback {
public:
WriteCallback(const std::string &templateFile, const
std::shared_ptr<core::FlowFile> &flow_file);
- int64_t process(std::shared_ptr<io::BaseStream> stream);
+ int64_t process(const std::shared_ptr<io::BaseStream>& stream);
Review comment:
as it turns out there are a number of implementations that store the
stream, so that (third-party) callbacks may access it, e.g.
`CompressContent::WriteCallback`, `JniByteInputStream`,
`FocusArchiveEntry::ReadCallback`, `ArchiveMerge::WriteCallback`,
`UnfocusArchiveEntry::WriteCallback`, `LuaInputStreamCallback`,
`PyOutputStreamCallback`, moreover the hash functions in `HashContent` expect a
`shared_ptr`
base on this coupled with the diff explosion that would result from
rewriting all the `stream->write` to `stream.write`, I propose we leave this be
for now, and return to it in a later PR
##########
File path: extensions/bustache/ApplyTemplate.h
##########
@@ -61,7 +61,7 @@ class ApplyTemplate : public core::Processor {
class WriteCallback : public OutputStreamCallback {
public:
WriteCallback(const std::string &templateFile, const
std::shared_ptr<core::FlowFile> &flow_file);
- int64_t process(std::shared_ptr<io::BaseStream> stream);
+ int64_t process(const std::shared_ptr<io::BaseStream>& stream);
Review comment:
as it turns out there are a number of implementations that store the
stream, so that callbacks may access it, e.g. `CompressContent::WriteCallback`,
`JniByteInputStream`, `FocusArchiveEntry::ReadCallback`,
`ArchiveMerge::WriteCallback`, `UnfocusArchiveEntry::WriteCallback`,
`LuaInputStreamCallback`, `PyOutputStreamCallback`, moreover the hash functions
in `HashContent` expect a `shared_ptr`
base on this coupled with the diff explosion that would result from
rewriting all the `stream->write` to `stream.write`, I propose we leave this be
for now, and return to it in a later PR
##########
File path: extensions/bustache/ApplyTemplate.h
##########
@@ -61,7 +61,7 @@ class ApplyTemplate : public core::Processor {
class WriteCallback : public OutputStreamCallback {
public:
WriteCallback(const std::string &templateFile, const
std::shared_ptr<core::FlowFile> &flow_file);
- int64_t process(std::shared_ptr<io::BaseStream> stream);
+ int64_t process(const std::shared_ptr<io::BaseStream>& stream);
Review comment:
I would say, that using `const shared_ptr<>&` is certainly an
improvement, as @lordgamez said it does not force us to take ownership, and it
is agreement with the proliferation of managed pointers in the rest of the
system (so it lets us call into interfaces expecting a managed ptr), I don't
have a strong opinion about it though, because I plan on removing the whole
`*StreamCallback` stuff, so if you feel like it should be changed, decide which
one should it be:
1. shared_ptr<BaseStream>
2. const shared_ptr<BaseStream>&
3. BaseStream&
4. BaseStream*
5. gsl::not_null<BaseStream&>
##########
File path: extensions/bustache/ApplyTemplate.h
##########
@@ -61,7 +61,7 @@ class ApplyTemplate : public core::Processor {
class WriteCallback : public OutputStreamCallback {
public:
WriteCallback(const std::string &templateFile, const
std::shared_ptr<core::FlowFile> &flow_file);
- int64_t process(std::shared_ptr<io::BaseStream> stream);
+ int64_t process(const std::shared_ptr<io::BaseStream>& stream);
Review comment:
I would say, that using `const shared_ptr<>&` is certainly an
improvement, as @lordgamez said it does not force us to take ownership, and it
is agreement with the proliferation of managed pointers in the rest of the
system (so it lets us call into interfaces expecting a managed ptr), I don't
have a strong opinion about it though, because I plan on removing the whole
`*StreamCallback` stuff, so if you feel like it should be changed, decide which
one should it be:
1. `shared_ptr<BaseStream>`
2. `const shared_ptr<BaseStream>&`
3. `BaseStream&`
4. `BaseStream*`
5. `gsl::not_null<BaseStream&>`
##########
File path: extensions/bustache/ApplyTemplate.h
##########
@@ -61,7 +61,7 @@ class ApplyTemplate : public core::Processor {
class WriteCallback : public OutputStreamCallback {
public:
WriteCallback(const std::string &templateFile, const
std::shared_ptr<core::FlowFile> &flow_file);
- int64_t process(std::shared_ptr<io::BaseStream> stream);
+ int64_t process(const std::shared_ptr<io::BaseStream>& stream);
Review comment:
I would say, that using `const shared_ptr<>&` is certainly an
improvement, as @lordgamez said it does not force us to take ownership, and it
is agreement with the proliferation of managed pointers in the rest of the
system (so it lets us call into interfaces expecting a managed ptr), I don't
have a strong opinion about it though, because I plan on removing the whole
`*StreamCallback` stuff, so if you feel like it should be changed, decide which
one should it be:
1. `shared_ptr<BaseStream>`
2. `const shared_ptr<BaseStream>&`
3. `BaseStream&`
4. `BaseStream*`
5. `gsl::not_null<BaseStream*>`
##########
File path: extensions/bustache/ApplyTemplate.h
##########
@@ -61,7 +61,7 @@ class ApplyTemplate : public core::Processor {
class WriteCallback : public OutputStreamCallback {
public:
WriteCallback(const std::string &templateFile, const
std::shared_ptr<core::FlowFile> &flow_file);
- int64_t process(std::shared_ptr<io::BaseStream> stream);
+ int64_t process(const std::shared_ptr<io::BaseStream>& stream);
Review comment:
I would say, that using `const shared_ptr<>&` is certainly an
improvement, as @lordgamez said it does not force us to take ownership, and it
is agreement with the proliferation of managed pointers in the rest of the
system (so it lets us call into interfaces expecting a managed ptr), I don't
have a strong opinion about it though, because I plan on removing the whole
`*StreamCallback` stuff, so if you feel like it should be changed, decide which
one it should be:
1. `shared_ptr<BaseStream>`
2. `const shared_ptr<BaseStream>&`
3. `BaseStream&`
4. `BaseStream*`
5. `gsl::not_null<BaseStream*>`
##########
File path: extensions/bustache/ApplyTemplate.h
##########
@@ -61,7 +61,7 @@ class ApplyTemplate : public core::Processor {
class WriteCallback : public OutputStreamCallback {
public:
WriteCallback(const std::string &templateFile, const
std::shared_ptr<core::FlowFile> &flow_file);
- int64_t process(std::shared_ptr<io::BaseStream> stream);
+ int64_t process(const std::shared_ptr<io::BaseStream>& stream);
Review comment:
as it turns out there are a number of implementations that store the
stream, so that (third-party) callbacks may access it, e.g.
`CompressContent::WriteCallback`, `JniByteInputStream`,
`FocusArchiveEntry::ReadCallback`, `ArchiveMerge::WriteCallback`,
`UnfocusArchiveEntry::WriteCallback`, `LuaInputStreamCallback`,
`PyOutputStreamCallback`, moreover the hash functions in `HashContent` expect a
`shared_ptr`
base on this coupled with the diff explosion that would result from
rewriting all the `stream->write` to `stream.write`, I propose we leave this be
for now, and return to it in a later PR
##########
File path: extensions/bustache/ApplyTemplate.h
##########
@@ -61,7 +61,7 @@ class ApplyTemplate : public core::Processor {
class WriteCallback : public OutputStreamCallback {
public:
WriteCallback(const std::string &templateFile, const
std::shared_ptr<core::FlowFile> &flow_file);
- int64_t process(std::shared_ptr<io::BaseStream> stream);
+ int64_t process(const std::shared_ptr<io::BaseStream>& stream);
Review comment:
as it turns out there are a number of implementations that store the
stream, so that callbacks may access it, e.g. `CompressContent::WriteCallback`,
`JniByteInputStream`, `FocusArchiveEntry::ReadCallback`,
`ArchiveMerge::WriteCallback`, `UnfocusArchiveEntry::WriteCallback`,
`LuaInputStreamCallback`, `PyOutputStreamCallback`, moreover the hash functions
in `HashContent` expect a `shared_ptr`
base on this coupled with the diff explosion that would result from
rewriting all the `stream->write` to `stream.write`, I propose we leave this be
for now, and return to it in a later PR
##########
File path: extensions/bustache/ApplyTemplate.h
##########
@@ -61,7 +61,7 @@ class ApplyTemplate : public core::Processor {
class WriteCallback : public OutputStreamCallback {
public:
WriteCallback(const std::string &templateFile, const
std::shared_ptr<core::FlowFile> &flow_file);
- int64_t process(std::shared_ptr<io::BaseStream> stream);
+ int64_t process(const std::shared_ptr<io::BaseStream>& stream);
Review comment:
I would say, that using `const shared_ptr<>&` is certainly an
improvement, as @lordgamez said it does not force us to take ownership, and it
is agreement with the proliferation of managed pointers in the rest of the
system (so it lets us call into interfaces expecting a managed ptr), I don't
have a strong opinion about it though, because I plan on removing the whole
`*StreamCallback` stuff, so if you feel like it should be changed, decide which
one should it be:
1. shared_ptr<BaseStream>
2. const shared_ptr<BaseStream>&
3. BaseStream&
4. BaseStream*
5. gsl::not_null<BaseStream&>
##########
File path: extensions/bustache/ApplyTemplate.h
##########
@@ -61,7 +61,7 @@ class ApplyTemplate : public core::Processor {
class WriteCallback : public OutputStreamCallback {
public:
WriteCallback(const std::string &templateFile, const
std::shared_ptr<core::FlowFile> &flow_file);
- int64_t process(std::shared_ptr<io::BaseStream> stream);
+ int64_t process(const std::shared_ptr<io::BaseStream>& stream);
Review comment:
I would say, that using `const shared_ptr<>&` is certainly an
improvement, as @lordgamez said it does not force us to take ownership, and it
is agreement with the proliferation of managed pointers in the rest of the
system (so it lets us call into interfaces expecting a managed ptr), I don't
have a strong opinion about it though, because I plan on removing the whole
`*StreamCallback` stuff, so if you feel like it should be changed, decide which
one should it be:
1. `shared_ptr<BaseStream>`
2. `const shared_ptr<BaseStream>&`
3. `BaseStream&`
4. `BaseStream*`
5. `gsl::not_null<BaseStream&>`
##########
File path: extensions/bustache/ApplyTemplate.h
##########
@@ -61,7 +61,7 @@ class ApplyTemplate : public core::Processor {
class WriteCallback : public OutputStreamCallback {
public:
WriteCallback(const std::string &templateFile, const
std::shared_ptr<core::FlowFile> &flow_file);
- int64_t process(std::shared_ptr<io::BaseStream> stream);
+ int64_t process(const std::shared_ptr<io::BaseStream>& stream);
Review comment:
I would say, that using `const shared_ptr<>&` is certainly an
improvement, as @lordgamez said it does not force us to take ownership, and it
is agreement with the proliferation of managed pointers in the rest of the
system (so it lets us call into interfaces expecting a managed ptr), I don't
have a strong opinion about it though, because I plan on removing the whole
`*StreamCallback` stuff, so if you feel like it should be changed, decide which
one should it be:
1. `shared_ptr<BaseStream>`
2. `const shared_ptr<BaseStream>&`
3. `BaseStream&`
4. `BaseStream*`
5. `gsl::not_null<BaseStream*>`
##########
File path: extensions/bustache/ApplyTemplate.h
##########
@@ -61,7 +61,7 @@ class ApplyTemplate : public core::Processor {
class WriteCallback : public OutputStreamCallback {
public:
WriteCallback(const std::string &templateFile, const
std::shared_ptr<core::FlowFile> &flow_file);
- int64_t process(std::shared_ptr<io::BaseStream> stream);
+ int64_t process(const std::shared_ptr<io::BaseStream>& stream);
Review comment:
I would say, that using `const shared_ptr<>&` is certainly an
improvement, as @lordgamez said it does not force us to take ownership, and it
is agreement with the proliferation of managed pointers in the rest of the
system (so it lets us call into interfaces expecting a managed ptr), I don't
have a strong opinion about it though, because I plan on removing the whole
`*StreamCallback` stuff, so if you feel like it should be changed, decide which
one it should be:
1. `shared_ptr<BaseStream>`
2. `const shared_ptr<BaseStream>&`
3. `BaseStream&`
4. `BaseStream*`
5. `gsl::not_null<BaseStream*>`
##########
File path: extensions/bustache/ApplyTemplate.h
##########
@@ -61,7 +61,7 @@ class ApplyTemplate : public core::Processor {
class WriteCallback : public OutputStreamCallback {
public:
WriteCallback(const std::string &templateFile, const
std::shared_ptr<core::FlowFile> &flow_file);
- int64_t process(std::shared_ptr<io::BaseStream> stream);
+ int64_t process(const std::shared_ptr<io::BaseStream>& stream);
Review comment:
as it turns out there are a number of implementations that store the
stream, so that (third-party) callbacks may access it, e.g.
`CompressContent::WriteCallback`, `JniByteInputStream`,
`FocusArchiveEntry::ReadCallback`, `ArchiveMerge::WriteCallback`,
`UnfocusArchiveEntry::WriteCallback`, `LuaInputStreamCallback`,
`PyOutputStreamCallback`, moreover the hash functions in `HashContent` expect a
`shared_ptr`
base on this coupled with the diff explosion that would result from
rewriting all the `stream->write` to `stream.write`, I propose we leave this be
for now, and return to it in a later PR
##########
File path: extensions/bustache/ApplyTemplate.h
##########
@@ -61,7 +61,7 @@ class ApplyTemplate : public core::Processor {
class WriteCallback : public OutputStreamCallback {
public:
WriteCallback(const std::string &templateFile, const
std::shared_ptr<core::FlowFile> &flow_file);
- int64_t process(std::shared_ptr<io::BaseStream> stream);
+ int64_t process(const std::shared_ptr<io::BaseStream>& stream);
Review comment:
as it turns out there are a number of implementations that store the
stream, so that callbacks may access it, e.g. `CompressContent::WriteCallback`,
`JniByteInputStream`, `FocusArchiveEntry::ReadCallback`,
`ArchiveMerge::WriteCallback`, `UnfocusArchiveEntry::WriteCallback`,
`LuaInputStreamCallback`, `PyOutputStreamCallback`, moreover the hash functions
in `HashContent` expect a `shared_ptr`
base on this coupled with the diff explosion that would result from
rewriting all the `stream->write` to `stream.write`, I propose we leave this be
for now, and return to it in a later PR
##########
File path: extensions/bustache/ApplyTemplate.h
##########
@@ -61,7 +61,7 @@ class ApplyTemplate : public core::Processor {
class WriteCallback : public OutputStreamCallback {
public:
WriteCallback(const std::string &templateFile, const
std::shared_ptr<core::FlowFile> &flow_file);
- int64_t process(std::shared_ptr<io::BaseStream> stream);
+ int64_t process(const std::shared_ptr<io::BaseStream>& stream);
Review comment:
I would say, that using `const shared_ptr<>&` is certainly an
improvement, as @lordgamez said it does not force us to take ownership, and it
is agreement with the proliferation of managed pointers in the rest of the
system (so it lets us call into interfaces expecting a managed ptr), I don't
have a strong opinion about it though, because I plan on removing the whole
`*StreamCallback` stuff, so if you feel like it should be changed, decide which
one should it be:
1. shared_ptr<BaseStream>
2. const shared_ptr<BaseStream>&
3. BaseStream&
4. BaseStream*
5. gsl::not_null<BaseStream&>
##########
File path: extensions/bustache/ApplyTemplate.h
##########
@@ -61,7 +61,7 @@ class ApplyTemplate : public core::Processor {
class WriteCallback : public OutputStreamCallback {
public:
WriteCallback(const std::string &templateFile, const
std::shared_ptr<core::FlowFile> &flow_file);
- int64_t process(std::shared_ptr<io::BaseStream> stream);
+ int64_t process(const std::shared_ptr<io::BaseStream>& stream);
Review comment:
I would say, that using `const shared_ptr<>&` is certainly an
improvement, as @lordgamez said it does not force us to take ownership, and it
is agreement with the proliferation of managed pointers in the rest of the
system (so it lets us call into interfaces expecting a managed ptr), I don't
have a strong opinion about it though, because I plan on removing the whole
`*StreamCallback` stuff, so if you feel like it should be changed, decide which
one should it be:
1. `shared_ptr<BaseStream>`
2. `const shared_ptr<BaseStream>&`
3. `BaseStream&`
4. `BaseStream*`
5. `gsl::not_null<BaseStream&>`
##########
File path: extensions/bustache/ApplyTemplate.h
##########
@@ -61,7 +61,7 @@ class ApplyTemplate : public core::Processor {
class WriteCallback : public OutputStreamCallback {
public:
WriteCallback(const std::string &templateFile, const
std::shared_ptr<core::FlowFile> &flow_file);
- int64_t process(std::shared_ptr<io::BaseStream> stream);
+ int64_t process(const std::shared_ptr<io::BaseStream>& stream);
Review comment:
I would say, that using `const shared_ptr<>&` is certainly an
improvement, as @lordgamez said it does not force us to take ownership, and it
is agreement with the proliferation of managed pointers in the rest of the
system (so it lets us call into interfaces expecting a managed ptr), I don't
have a strong opinion about it though, because I plan on removing the whole
`*StreamCallback` stuff, so if you feel like it should be changed, decide which
one should it be:
1. `shared_ptr<BaseStream>`
2. `const shared_ptr<BaseStream>&`
3. `BaseStream&`
4. `BaseStream*`
5. `gsl::not_null<BaseStream*>`
##########
File path: extensions/bustache/ApplyTemplate.h
##########
@@ -61,7 +61,7 @@ class ApplyTemplate : public core::Processor {
class WriteCallback : public OutputStreamCallback {
public:
WriteCallback(const std::string &templateFile, const
std::shared_ptr<core::FlowFile> &flow_file);
- int64_t process(std::shared_ptr<io::BaseStream> stream);
+ int64_t process(const std::shared_ptr<io::BaseStream>& stream);
Review comment:
I would say, that using `const shared_ptr<>&` is certainly an
improvement, as @lordgamez said it does not force us to take ownership, and it
is agreement with the proliferation of managed pointers in the rest of the
system (so it lets us call into interfaces expecting a managed ptr), I don't
have a strong opinion about it though, because I plan on removing the whole
`*StreamCallback` stuff, so if you feel like it should be changed, decide which
one it should be:
1. `shared_ptr<BaseStream>`
2. `const shared_ptr<BaseStream>&`
3. `BaseStream&`
4. `BaseStream*`
5. `gsl::not_null<BaseStream*>`
##########
File path: extensions/bustache/ApplyTemplate.h
##########
@@ -61,7 +61,7 @@ class ApplyTemplate : public core::Processor {
class WriteCallback : public OutputStreamCallback {
public:
WriteCallback(const std::string &templateFile, const
std::shared_ptr<core::FlowFile> &flow_file);
- int64_t process(std::shared_ptr<io::BaseStream> stream);
+ int64_t process(const std::shared_ptr<io::BaseStream>& stream);
Review comment:
as it turns out there are a number of implementations that store the
stream, so that (third-party) callbacks may access it, e.g.
`CompressContent::WriteCallback`, `JniByteInputStream`,
`FocusArchiveEntry::ReadCallback`, `ArchiveMerge::WriteCallback`,
`UnfocusArchiveEntry::WriteCallback`, `LuaInputStreamCallback`,
`PyOutputStreamCallback`, moreover the hash functions in `HashContent` expect a
`shared_ptr`
base on this coupled with the diff explosion that would result from
rewriting all the `stream->write` to `stream.write`, I propose we leave this be
for now, and return to it in a later PR
##########
File path: extensions/bustache/ApplyTemplate.h
##########
@@ -61,7 +61,7 @@ class ApplyTemplate : public core::Processor {
class WriteCallback : public OutputStreamCallback {
public:
WriteCallback(const std::string &templateFile, const
std::shared_ptr<core::FlowFile> &flow_file);
- int64_t process(std::shared_ptr<io::BaseStream> stream);
+ int64_t process(const std::shared_ptr<io::BaseStream>& stream);
Review comment:
as it turns out there are a number of implementations that store the
stream, so that callbacks may access it, e.g. `CompressContent::WriteCallback`,
`JniByteInputStream`, `FocusArchiveEntry::ReadCallback`,
`ArchiveMerge::WriteCallback`, `UnfocusArchiveEntry::WriteCallback`,
`LuaInputStreamCallback`, `PyOutputStreamCallback`, moreover the hash functions
in `HashContent` expect a `shared_ptr`
base on this coupled with the diff explosion that would result from
rewriting all the `stream->write` to `stream.write`, I propose we leave this be
for now, and return to it in a later PR
##########
File path: extensions/bustache/ApplyTemplate.h
##########
@@ -61,7 +61,7 @@ class ApplyTemplate : public core::Processor {
class WriteCallback : public OutputStreamCallback {
public:
WriteCallback(const std::string &templateFile, const
std::shared_ptr<core::FlowFile> &flow_file);
- int64_t process(std::shared_ptr<io::BaseStream> stream);
+ int64_t process(const std::shared_ptr<io::BaseStream>& stream);
Review comment:
I would say, that using `const shared_ptr<>&` is certainly an
improvement, as @lordgamez said it does not force us to take ownership, and it
is agreement with the proliferation of managed pointers in the rest of the
system (so it lets us call into interfaces expecting a managed ptr), I don't
have a strong opinion about it though, because I plan on removing the whole
`*StreamCallback` stuff, so if you feel like it should be changed, decide which
one should it be:
1. shared_ptr<BaseStream>
2. const shared_ptr<BaseStream>&
3. BaseStream&
4. BaseStream*
5. gsl::not_null<BaseStream&>
##########
File path: extensions/bustache/ApplyTemplate.h
##########
@@ -61,7 +61,7 @@ class ApplyTemplate : public core::Processor {
class WriteCallback : public OutputStreamCallback {
public:
WriteCallback(const std::string &templateFile, const
std::shared_ptr<core::FlowFile> &flow_file);
- int64_t process(std::shared_ptr<io::BaseStream> stream);
+ int64_t process(const std::shared_ptr<io::BaseStream>& stream);
Review comment:
I would say, that using `const shared_ptr<>&` is certainly an
improvement, as @lordgamez said it does not force us to take ownership, and it
is agreement with the proliferation of managed pointers in the rest of the
system (so it lets us call into interfaces expecting a managed ptr), I don't
have a strong opinion about it though, because I plan on removing the whole
`*StreamCallback` stuff, so if you feel like it should be changed, decide which
one should it be:
1. `shared_ptr<BaseStream>`
2. `const shared_ptr<BaseStream>&`
3. `BaseStream&`
4. `BaseStream*`
5. `gsl::not_null<BaseStream&>`
##########
File path: extensions/bustache/ApplyTemplate.h
##########
@@ -61,7 +61,7 @@ class ApplyTemplate : public core::Processor {
class WriteCallback : public OutputStreamCallback {
public:
WriteCallback(const std::string &templateFile, const
std::shared_ptr<core::FlowFile> &flow_file);
- int64_t process(std::shared_ptr<io::BaseStream> stream);
+ int64_t process(const std::shared_ptr<io::BaseStream>& stream);
Review comment:
I would say, that using `const shared_ptr<>&` is certainly an
improvement, as @lordgamez said it does not force us to take ownership, and it
is agreement with the proliferation of managed pointers in the rest of the
system (so it lets us call into interfaces expecting a managed ptr), I don't
have a strong opinion about it though, because I plan on removing the whole
`*StreamCallback` stuff, so if you feel like it should be changed, decide which
one should it be:
1. `shared_ptr<BaseStream>`
2. `const shared_ptr<BaseStream>&`
3. `BaseStream&`
4. `BaseStream*`
5. `gsl::not_null<BaseStream*>`
##########
File path: extensions/bustache/ApplyTemplate.h
##########
@@ -61,7 +61,7 @@ class ApplyTemplate : public core::Processor {
class WriteCallback : public OutputStreamCallback {
public:
WriteCallback(const std::string &templateFile, const
std::shared_ptr<core::FlowFile> &flow_file);
- int64_t process(std::shared_ptr<io::BaseStream> stream);
+ int64_t process(const std::shared_ptr<io::BaseStream>& stream);
Review comment:
I would say, that using `const shared_ptr<>&` is certainly an
improvement, as @lordgamez said it does not force us to take ownership, and it
is agreement with the proliferation of managed pointers in the rest of the
system (so it lets us call into interfaces expecting a managed ptr), I don't
have a strong opinion about it though, because I plan on removing the whole
`*StreamCallback` stuff, so if you feel like it should be changed, decide which
one it should be:
1. `shared_ptr<BaseStream>`
2. `const shared_ptr<BaseStream>&`
3. `BaseStream&`
4. `BaseStream*`
5. `gsl::not_null<BaseStream*>`
##########
File path: extensions/bustache/ApplyTemplate.h
##########
@@ -61,7 +61,7 @@ class ApplyTemplate : public core::Processor {
class WriteCallback : public OutputStreamCallback {
public:
WriteCallback(const std::string &templateFile, const
std::shared_ptr<core::FlowFile> &flow_file);
- int64_t process(std::shared_ptr<io::BaseStream> stream);
+ int64_t process(const std::shared_ptr<io::BaseStream>& stream);
Review comment:
as it turns out there are a number of implementations that store the
stream, so that (third-party) callbacks may access it, e.g.
`CompressContent::WriteCallback`, `JniByteInputStream`,
`FocusArchiveEntry::ReadCallback`, `ArchiveMerge::WriteCallback`,
`UnfocusArchiveEntry::WriteCallback`, `LuaInputStreamCallback`,
`PyOutputStreamCallback`, moreover the hash functions in `HashContent` expect a
`shared_ptr`
base on this coupled with the diff explosion that would result from
rewriting all the `stream->write` to `stream.write`, I propose we leave this be
for now, and return to it in a later PR
##########
File path: extensions/bustache/ApplyTemplate.h
##########
@@ -61,7 +61,7 @@ class ApplyTemplate : public core::Processor {
class WriteCallback : public OutputStreamCallback {
public:
WriteCallback(const std::string &templateFile, const
std::shared_ptr<core::FlowFile> &flow_file);
- int64_t process(std::shared_ptr<io::BaseStream> stream);
+ int64_t process(const std::shared_ptr<io::BaseStream>& stream);
Review comment:
as it turns out there are a number of implementations that store the
stream, so that callbacks may access it, e.g. `CompressContent::WriteCallback`,
`JniByteInputStream`, `FocusArchiveEntry::ReadCallback`,
`ArchiveMerge::WriteCallback`, `UnfocusArchiveEntry::WriteCallback`,
`LuaInputStreamCallback`, `PyOutputStreamCallback`, moreover the hash functions
in `HashContent` expect a `shared_ptr`
base on this coupled with the diff explosion that would result from
rewriting all the `stream->write` to `stream.write`, I propose we leave this be
for now, and return to it in a later PR
##########
File path: extensions/bustache/ApplyTemplate.h
##########
@@ -61,7 +61,7 @@ class ApplyTemplate : public core::Processor {
class WriteCallback : public OutputStreamCallback {
public:
WriteCallback(const std::string &templateFile, const
std::shared_ptr<core::FlowFile> &flow_file);
- int64_t process(std::shared_ptr<io::BaseStream> stream);
+ int64_t process(const std::shared_ptr<io::BaseStream>& stream);
Review comment:
I would say, that using `const shared_ptr<>&` is certainly an
improvement, as @lordgamez said it does not force us to take ownership, and it
is agreement with the proliferation of managed pointers in the rest of the
system (so it lets us call into interfaces expecting a managed ptr), I don't
have a strong opinion about it though, because I plan on removing the whole
`*StreamCallback` stuff, so if you feel like it should be changed, decide which
one should it be:
1. shared_ptr<BaseStream>
2. const shared_ptr<BaseStream>&
3. BaseStream&
4. BaseStream*
5. gsl::not_null<BaseStream&>
##########
File path: extensions/bustache/ApplyTemplate.h
##########
@@ -61,7 +61,7 @@ class ApplyTemplate : public core::Processor {
class WriteCallback : public OutputStreamCallback {
public:
WriteCallback(const std::string &templateFile, const
std::shared_ptr<core::FlowFile> &flow_file);
- int64_t process(std::shared_ptr<io::BaseStream> stream);
+ int64_t process(const std::shared_ptr<io::BaseStream>& stream);
Review comment:
I would say, that using `const shared_ptr<>&` is certainly an
improvement, as @lordgamez said it does not force us to take ownership, and it
is agreement with the proliferation of managed pointers in the rest of the
system (so it lets us call into interfaces expecting a managed ptr), I don't
have a strong opinion about it though, because I plan on removing the whole
`*StreamCallback` stuff, so if you feel like it should be changed, decide which
one should it be:
1. `shared_ptr<BaseStream>`
2. `const shared_ptr<BaseStream>&`
3. `BaseStream&`
4. `BaseStream*`
5. `gsl::not_null<BaseStream&>`
##########
File path: extensions/bustache/ApplyTemplate.h
##########
@@ -61,7 +61,7 @@ class ApplyTemplate : public core::Processor {
class WriteCallback : public OutputStreamCallback {
public:
WriteCallback(const std::string &templateFile, const
std::shared_ptr<core::FlowFile> &flow_file);
- int64_t process(std::shared_ptr<io::BaseStream> stream);
+ int64_t process(const std::shared_ptr<io::BaseStream>& stream);
Review comment:
I would say, that using `const shared_ptr<>&` is certainly an
improvement, as @lordgamez said it does not force us to take ownership, and it
is agreement with the proliferation of managed pointers in the rest of the
system (so it lets us call into interfaces expecting a managed ptr), I don't
have a strong opinion about it though, because I plan on removing the whole
`*StreamCallback` stuff, so if you feel like it should be changed, decide which
one should it be:
1. `shared_ptr<BaseStream>`
2. `const shared_ptr<BaseStream>&`
3. `BaseStream&`
4. `BaseStream*`
5. `gsl::not_null<BaseStream*>`
##########
File path: extensions/bustache/ApplyTemplate.h
##########
@@ -61,7 +61,7 @@ class ApplyTemplate : public core::Processor {
class WriteCallback : public OutputStreamCallback {
public:
WriteCallback(const std::string &templateFile, const
std::shared_ptr<core::FlowFile> &flow_file);
- int64_t process(std::shared_ptr<io::BaseStream> stream);
+ int64_t process(const std::shared_ptr<io::BaseStream>& stream);
Review comment:
I would say, that using `const shared_ptr<>&` is certainly an
improvement, as @lordgamez said it does not force us to take ownership, and it
is agreement with the proliferation of managed pointers in the rest of the
system (so it lets us call into interfaces expecting a managed ptr), I don't
have a strong opinion about it though, because I plan on removing the whole
`*StreamCallback` stuff, so if you feel like it should be changed, decide which
one it should be:
1. `shared_ptr<BaseStream>`
2. `const shared_ptr<BaseStream>&`
3. `BaseStream&`
4. `BaseStream*`
5. `gsl::not_null<BaseStream*>`
##########
File path: extensions/bustache/ApplyTemplate.h
##########
@@ -61,7 +61,7 @@ class ApplyTemplate : public core::Processor {
class WriteCallback : public OutputStreamCallback {
public:
WriteCallback(const std::string &templateFile, const
std::shared_ptr<core::FlowFile> &flow_file);
- int64_t process(std::shared_ptr<io::BaseStream> stream);
+ int64_t process(const std::shared_ptr<io::BaseStream>& stream);
Review comment:
as it turns out there are a number of implementations that store the
stream, so that (third-party) callbacks may access it, e.g.
`CompressContent::WriteCallback`, `JniByteInputStream`,
`FocusArchiveEntry::ReadCallback`, `ArchiveMerge::WriteCallback`,
`UnfocusArchiveEntry::WriteCallback`, `LuaInputStreamCallback`,
`PyOutputStreamCallback`, moreover the hash functions in `HashContent` expect a
`shared_ptr`
base on this coupled with the diff explosion that would result from
rewriting all the `stream->write` to `stream.write`, I propose we leave this be
for now, and return to it in a later PR
##########
File path: extensions/bustache/ApplyTemplate.h
##########
@@ -61,7 +61,7 @@ class ApplyTemplate : public core::Processor {
class WriteCallback : public OutputStreamCallback {
public:
WriteCallback(const std::string &templateFile, const
std::shared_ptr<core::FlowFile> &flow_file);
- int64_t process(std::shared_ptr<io::BaseStream> stream);
+ int64_t process(const std::shared_ptr<io::BaseStream>& stream);
Review comment:
as it turns out there are a number of implementations that store the
stream, so that callbacks may access it, e.g. `CompressContent::WriteCallback`,
`JniByteInputStream`, `FocusArchiveEntry::ReadCallback`,
`ArchiveMerge::WriteCallback`, `UnfocusArchiveEntry::WriteCallback`,
`LuaInputStreamCallback`, `PyOutputStreamCallback`, moreover the hash functions
in `HashContent` expect a `shared_ptr`
base on this coupled with the diff explosion that would result from
rewriting all the `stream->write` to `stream.write`, I propose we leave this be
for now, and return to it in a later PR
##########
File path: extensions/bustache/ApplyTemplate.h
##########
@@ -61,7 +61,7 @@ class ApplyTemplate : public core::Processor {
class WriteCallback : public OutputStreamCallback {
public:
WriteCallback(const std::string &templateFile, const
std::shared_ptr<core::FlowFile> &flow_file);
- int64_t process(std::shared_ptr<io::BaseStream> stream);
+ int64_t process(const std::shared_ptr<io::BaseStream>& stream);
Review comment:
I would say, that using `const shared_ptr<>&` is certainly an
improvement, as @lordgamez said it does not force us to take ownership, and it
is agreement with the proliferation of managed pointers in the rest of the
system (so it lets us call into interfaces expecting a managed ptr), I don't
have a strong opinion about it though, because I plan on removing the whole
`*StreamCallback` stuff, so if you feel like it should be changed, decide which
one should it be:
1. shared_ptr<BaseStream>
2. const shared_ptr<BaseStream>&
3. BaseStream&
4. BaseStream*
5. gsl::not_null<BaseStream&>
##########
File path: extensions/bustache/ApplyTemplate.h
##########
@@ -61,7 +61,7 @@ class ApplyTemplate : public core::Processor {
class WriteCallback : public OutputStreamCallback {
public:
WriteCallback(const std::string &templateFile, const
std::shared_ptr<core::FlowFile> &flow_file);
- int64_t process(std::shared_ptr<io::BaseStream> stream);
+ int64_t process(const std::shared_ptr<io::BaseStream>& stream);
Review comment:
I would say, that using `const shared_ptr<>&` is certainly an
improvement, as @lordgamez said it does not force us to take ownership, and it
is agreement with the proliferation of managed pointers in the rest of the
system (so it lets us call into interfaces expecting a managed ptr), I don't
have a strong opinion about it though, because I plan on removing the whole
`*StreamCallback` stuff, so if you feel like it should be changed, decide which
one should it be:
1. shared_ptr<BaseStream>
2. const shared_ptr<BaseStream>&
3. BaseStream&
4. BaseStream*
5. gsl::not_null<BaseStream&>
##########
File path: extensions/bustache/ApplyTemplate.h
##########
@@ -61,7 +61,7 @@ class ApplyTemplate : public core::Processor {
class WriteCallback : public OutputStreamCallback {
public:
WriteCallback(const std::string &templateFile, const
std::shared_ptr<core::FlowFile> &flow_file);
- int64_t process(std::shared_ptr<io::BaseStream> stream);
+ int64_t process(const std::shared_ptr<io::BaseStream>& stream);
Review comment:
I would say, that using `const shared_ptr<>&` is certainly an
improvement, as @lordgamez said it does not force us to take ownership, and it
is agreement with the proliferation of managed pointers in the rest of the
system (so it lets us call into interfaces expecting a managed ptr), I don't
have a strong opinion about it though, because I plan on removing the whole
`*StreamCallback` stuff, so if you feel like it should be changed, decide which
one should it be:
1. `shared_ptr<BaseStream>`
2. `const shared_ptr<BaseStream>&`
3. `BaseStream&`
4. `BaseStream*`
5. `gsl::not_null<BaseStream&>`
##########
File path: extensions/bustache/ApplyTemplate.h
##########
@@ -61,7 +61,7 @@ class ApplyTemplate : public core::Processor {
class WriteCallback : public OutputStreamCallback {
public:
WriteCallback(const std::string &templateFile, const
std::shared_ptr<core::FlowFile> &flow_file);
- int64_t process(std::shared_ptr<io::BaseStream> stream);
+ int64_t process(const std::shared_ptr<io::BaseStream>& stream);
Review comment:
I would say, that using `const shared_ptr<>&` is certainly an
improvement, as @lordgamez said it does not force us to take ownership, and it
is agreement with the proliferation of managed pointers in the rest of the
system (so it lets us call into interfaces expecting a managed ptr), I don't
have a strong opinion about it though, because I plan on removing the whole
`*StreamCallback` stuff, so if you feel like it should be changed, decide which
one should it be:
1. `shared_ptr<BaseStream>`
2. `const shared_ptr<BaseStream>&`
3. `BaseStream&`
4. `BaseStream*`
5. `gsl::not_null<BaseStream*>`
##########
File path: extensions/bustache/ApplyTemplate.h
##########
@@ -61,7 +61,7 @@ class ApplyTemplate : public core::Processor {
class WriteCallback : public OutputStreamCallback {
public:
WriteCallback(const std::string &templateFile, const
std::shared_ptr<core::FlowFile> &flow_file);
- int64_t process(std::shared_ptr<io::BaseStream> stream);
+ int64_t process(const std::shared_ptr<io::BaseStream>& stream);
Review comment:
I would say, that using `const shared_ptr<>&` is certainly an
improvement, as @lordgamez said it does not force us to take ownership, and it
is agreement with the proliferation of managed pointers in the rest of the
system (so it lets us call into interfaces expecting a managed ptr), I don't
have a strong opinion about it though, because I plan on removing the whole
`*StreamCallback` stuff, so if you feel like it should be changed, decide which
one it should be:
1. `shared_ptr<BaseStream>`
2. `const shared_ptr<BaseStream>&`
3. `BaseStream&`
4. `BaseStream*`
5. `gsl::not_null<BaseStream*>`
##########
File path: extensions/bustache/ApplyTemplate.h
##########
@@ -61,7 +61,7 @@ class ApplyTemplate : public core::Processor {
class WriteCallback : public OutputStreamCallback {
public:
WriteCallback(const std::string &templateFile, const
std::shared_ptr<core::FlowFile> &flow_file);
- int64_t process(std::shared_ptr<io::BaseStream> stream);
+ int64_t process(const std::shared_ptr<io::BaseStream>& stream);
Review comment:
as it turns out there are a number of implementations that store the
stream, so that (third-party) callbacks may access it, e.g.
`CompressContent::WriteCallback`, `JniByteInputStream`,
`FocusArchiveEntry::ReadCallback`, `ArchiveMerge::WriteCallback`,
`UnfocusArchiveEntry::WriteCallback`, `LuaInputStreamCallback`,
`PyOutputStreamCallback`, moreover the hash functions in `HashContent` expect a
`shared_ptr`
base on this coupled with the diff explosion that would result from
rewriting all the `stream->write` to `stream.write`, I propose we leave this be
for now, and return to it in a later PR
##########
File path: extensions/bustache/ApplyTemplate.h
##########
@@ -61,7 +61,7 @@ class ApplyTemplate : public core::Processor {
class WriteCallback : public OutputStreamCallback {
public:
WriteCallback(const std::string &templateFile, const
std::shared_ptr<core::FlowFile> &flow_file);
- int64_t process(std::shared_ptr<io::BaseStream> stream);
+ int64_t process(const std::shared_ptr<io::BaseStream>& stream);
Review comment:
as it turns out there are a number of implementations that store the
stream, so that callbacks may access it, e.g. `CompressContent::WriteCallback`,
`JniByteInputStream`, `FocusArchiveEntry::ReadCallback`,
`ArchiveMerge::WriteCallback`, `UnfocusArchiveEntry::WriteCallback`,
`LuaInputStreamCallback`, `PyOutputStreamCallback`, moreover the hash functions
in `HashContent` expect a `shared_ptr`
base on this coupled with the diff explosion that would result from
rewriting all the `stream->write` to `stream.write`, I propose we leave this be
for now, and return to it in a later PR
##########
File path: extensions/bustache/ApplyTemplate.h
##########
@@ -61,7 +61,7 @@ class ApplyTemplate : public core::Processor {
class WriteCallback : public OutputStreamCallback {
public:
WriteCallback(const std::string &templateFile, const
std::shared_ptr<core::FlowFile> &flow_file);
- int64_t process(std::shared_ptr<io::BaseStream> stream);
+ int64_t process(const std::shared_ptr<io::BaseStream>& stream);
Review comment:
I would say, that using `const shared_ptr<>&` is certainly an
improvement, as @lordgamez said it does not force us to take ownership, and it
is agreement with the proliferation of managed pointers in the rest of the
system (so it lets us call into interfaces expecting a managed ptr), I don't
have a strong opinion about it though, because I plan on removing the whole
`*StreamCallback` stuff, so if you feel like it should be changed, decide which
one should it be:
1. shared_ptr<BaseStream>
2. const shared_ptr<BaseStream>&
3. BaseStream&
4. BaseStream*
5. gsl::not_null<BaseStream&>
##########
File path: extensions/bustache/ApplyTemplate.h
##########
@@ -61,7 +61,7 @@ class ApplyTemplate : public core::Processor {
class WriteCallback : public OutputStreamCallback {
public:
WriteCallback(const std::string &templateFile, const
std::shared_ptr<core::FlowFile> &flow_file);
- int64_t process(std::shared_ptr<io::BaseStream> stream);
+ int64_t process(const std::shared_ptr<io::BaseStream>& stream);
Review comment:
I would say, that using `const shared_ptr<>&` is certainly an
improvement, as @lordgamez said it does not force us to take ownership, and it
is agreement with the proliferation of managed pointers in the rest of the
system (so it lets us call into interfaces expecting a managed ptr), I don't
have a strong opinion about it though, because I plan on removing the whole
`*StreamCallback` stuff, so if you feel like it should be changed, decide which
one should it be:
1. `shared_ptr<BaseStream>`
2. `const shared_ptr<BaseStream>&`
3. `BaseStream&`
4. `BaseStream*`
5. `gsl::not_null<BaseStream&>`
##########
File path: extensions/bustache/ApplyTemplate.h
##########
@@ -61,7 +61,7 @@ class ApplyTemplate : public core::Processor {
class WriteCallback : public OutputStreamCallback {
public:
WriteCallback(const std::string &templateFile, const
std::shared_ptr<core::FlowFile> &flow_file);
- int64_t process(std::shared_ptr<io::BaseStream> stream);
+ int64_t process(const std::shared_ptr<io::BaseStream>& stream);
Review comment:
I would say, that using `const shared_ptr<>&` is certainly an
improvement, as @lordgamez said it does not force us to take ownership, and it
is agreement with the proliferation of managed pointers in the rest of the
system (so it lets us call into interfaces expecting a managed ptr), I don't
have a strong opinion about it though, because I plan on removing the whole
`*StreamCallback` stuff, so if you feel like it should be changed, decide which
one should it be:
1. `shared_ptr<BaseStream>`
2. `const shared_ptr<BaseStream>&`
3. `BaseStream&`
4. `BaseStream*`
5. `gsl::not_null<BaseStream*>`
##########
File path: extensions/bustache/ApplyTemplate.h
##########
@@ -61,7 +61,7 @@ class ApplyTemplate : public core::Processor {
class WriteCallback : public OutputStreamCallback {
public:
WriteCallback(const std::string &templateFile, const
std::shared_ptr<core::FlowFile> &flow_file);
- int64_t process(std::shared_ptr<io::BaseStream> stream);
+ int64_t process(const std::shared_ptr<io::BaseStream>& stream);
Review comment:
I would say, that using `const shared_ptr<>&` is certainly an
improvement, as @lordgamez said it does not force us to take ownership, and it
is agreement with the proliferation of managed pointers in the rest of the
system (so it lets us call into interfaces expecting a managed ptr), I don't
have a strong opinion about it though, because I plan on removing the whole
`*StreamCallback` stuff, so if you feel like it should be changed, decide which
one it should be:
1. `shared_ptr<BaseStream>`
2. `const shared_ptr<BaseStream>&`
3. `BaseStream&`
4. `BaseStream*`
5. `gsl::not_null<BaseStream*>`
##########
File path: extensions/bustache/ApplyTemplate.h
##########
@@ -61,7 +61,7 @@ class ApplyTemplate : public core::Processor {
class WriteCallback : public OutputStreamCallback {
public:
WriteCallback(const std::string &templateFile, const
std::shared_ptr<core::FlowFile> &flow_file);
- int64_t process(std::shared_ptr<io::BaseStream> stream);
+ int64_t process(const std::shared_ptr<io::BaseStream>& stream);
Review comment:
as it turns out there are a number of implementations that store the
stream, so that (third-party) callbacks may access it, e.g.
`CompressContent::WriteCallback`, `JniByteInputStream`,
`FocusArchiveEntry::ReadCallback`, `ArchiveMerge::WriteCallback`,
`UnfocusArchiveEntry::WriteCallback`, `LuaInputStreamCallback`,
`PyOutputStreamCallback`, moreover the hash functions in `HashContent` expect a
`shared_ptr`
base on this coupled with the diff explosion that would result from
rewriting all the `stream->write` to `stream.write`, I propose we leave this be
for now, and return to it in a later PR
##########
File path: extensions/bustache/ApplyTemplate.h
##########
@@ -61,7 +61,7 @@ class ApplyTemplate : public core::Processor {
class WriteCallback : public OutputStreamCallback {
public:
WriteCallback(const std::string &templateFile, const
std::shared_ptr<core::FlowFile> &flow_file);
- int64_t process(std::shared_ptr<io::BaseStream> stream);
+ int64_t process(const std::shared_ptr<io::BaseStream>& stream);
Review comment:
as it turns out there are a number of implementations that store the
stream, so that callbacks may access it, e.g. `CompressContent::WriteCallback`,
`JniByteInputStream`, `FocusArchiveEntry::ReadCallback`,
`ArchiveMerge::WriteCallback`, `UnfocusArchiveEntry::WriteCallback`,
`LuaInputStreamCallback`, `PyOutputStreamCallback`, moreover the hash functions
in `HashContent` expect a `shared_ptr`
base on this coupled with the diff explosion that would result from
rewriting all the `stream->write` to `stream.write`, I propose we leave this be
for now, and return to it in a later PR
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
